I am using the test and quality 2.4G wifi extremely bad, 20mhz is 6 Mb, 40mhz is 54Mb, wifi always disconnected automatically, too disappointed 
I just saw an update for mt76xx,
But there is no improvement in the 2.4ghz band 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4fd9a5667eab6a75d8c3b7a1510dfb354ecca969
Please note that MT7621 doesn't come with either EHCI or OHCI controller, both USB2.0 and USB3.0 are controlled by its XHCI. Thus if you disable XHCI you disable USB completely.
If you want to force USB2.0 mode, just plug your USB3.0 device halfway into the USB port at some point where USB2.0 pins are connected while USB3.0 pins are disconnected.
Interesting, but then how does the Padavan firmware force USB2 mode?
It's a parameter passed into the XHCI driver module
At trunk/linux-3.4.x/drivers/usb/host/xhci.c line 49:
int usb3_disable = 0;
module_param(usb3_disable, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(usb3_disable, "Disable USB3 interface");
And it disables USB3.0 port power if usb3_disable is set
At trunk/linux-3.4.x/drivers/usb/host/xhci-hub.c line 838:
if (usb3_disable && hcd->speed == HCD_USB3)
xhci_writel(xhci, temp & ~PORT_POWER, port_array[wIndex]);
else
xhci_writel(xhci, temp | PORT_POWER, port_array[wIndex]);
5 Likes
Here, I made a patch to force USB2. It's very basic and can't be configured. Someone more experienced should mainline this.
How to, by building your own image:
- Follow https://openwrt.org/docs/guide-user/additional-software/beginners-build-guide
- Add the .patch in openwrt/target/linux/ramips/patches-4.14/
https://framadrop.org/r/TSBEYUBp-1#8SwUOXRF2MXzJfzmnx/43O9M2IPWKH/0SPD604V+J9I= - Run make again
- Flash the sysupgrade file
- Enjoy !
(Please see the link for how to build a stable release vs snapshot, snapshots have no UI by default)
USB and 2.4Ghz works fine for me now !
Thanks to LGA1150 for the detailed info 
6 Likes
Also see this link:
https://openwrt.org/docs/guide-developer/quickstart-build-images
I find it much easier to understand.
I am experiencing severe problems with wireless. 5GHz can't be searched by win10 laptop, but my Mi 5 can (not stable).
1 Like
after install snapshot ( 17.12.18 ) wifi and usb not work
use different channel
I may consider to buy this device.
So there are only problems, if I use USB 3.0 and 2.4GHz at the same time?
Do I need to disable USB 3.0 drivers for stable 2.4GHz wifi even if I don't use the USB port?
Please tell me If I understood something wrong.
And by the way thanks for sharing your solution.
I use your advice, everything works for me usb and 2.4Ghz, thank you everyone!
I've been playing around with this device. What I've noticed so far is that using this patch to disable usb3 doesn't do that much to improve wifi speeds. I think the most impact has the fact that folks have been working on the opensource driver:
If you're following LucyLight's advice you will indeed get the latest drivers in - however the same can be done by flashing the latest snapshot.
I've done some tests (not conclusive might i add) with the latest "official" snapshot and a snapshot with USB3 disables using the patch.
The only difference i noticed was that usb3 was disabled :). That and the fact that when i plugged a usb3 harddrive the router died the first time and then i saw weird errors:
[ 93.472005] usb 2-1: new SuperSpeed USB device number 2 using xhci-mtk
[ 93.506434] scsi host0: uas
[ 93.510324] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 4
[ 93.518763] xhci-mtk 1e1c0000.xhci: @000000000f7ca170 0dc18000 00000000 05000000 01058001
[ 93.526908] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 6
[ 93.535314] xhci-mtk 1e1c0000.xhci: @000000000f7ca180 0dc18100 00000000 05000000 01078001
[ 114.461636] scsi 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[ 114.469204] scsi 0:0:0:0: tag#0 CDB: opcode=0x12 12 00 00 00 24 00
[ 114.475520] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
[ 114.485307] xhci-mtk 1e1c0000.xhci: ep deq seg = 8dc01200, deq ptr = aead8010
[ 115.551601] scsi host0: uas_eh_device_reset_handler FAILED to get lock err -16
Mind you this is from the stock snapshot.
With the patch that disables USB3 the drive connects properly:
[ 762.864874] usb 1-1: new high-speed USB device number 4 using xhci-mtk
[ 763.058565] scsi host0: uas
[ 763.062822] scsi 0:0:0:0: Direct-Access Seagate Expansion 0708 PQ: 0 ANSI: 6
[ 764.866108] sd 0:0:0:0: [sda] 1953525167 512-byte logical blocks: (1.00 TB/932 GiB)
[ 764.873767] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 764.879344] sd 0:0:0:0: [sda] Write Protect is off
[ 764.884133] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[ 764.884573] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 764.991112] sda: sda1 sda2 sda3 sda4
[ 764.998675] sd 0:0:0:0: [sda] Attached SCSI disk
But at usb2 speeds as expected.
TLDR: Just flash the latest snapshot.
Sorry to be a pest, but I'm stuck.
I have recently installed openwrt[1] on a xiaomi 3rg, aka mir3g. The 5G wireless isn't working and I need advise about how to diagnose what's wrong.
- Thanks for any help! - ben
Details:
When enabled the GUI shows the radio as 0%.
I can scan for access points, i can even attach to one of them.
Things that don't change the situation:
- restarting the radio
- changing the channel, ssid, encryption.
- changing the number of wifi-iface.
- restoring a config from backup.
- rebooting, of course
This is my config, radio1 is the problem.
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
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 encryption 'psk2'
option key 'secretsanta'
option ssid 'wireless@cozy.org'
config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'pci0000:00/0000:00:01.0/0000:02:00.0'
option htmode 'VHT80'
option country '00'
option legacy_rates '1'
option channel '112'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option encryption 'psk2'
option key 'secretsanta'
option ssid 'wireless-5g-new@cozy.org'
[1] OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)
Hey Ben,
Try setting the channel manually - i remember reading somewhere that the driver gets confused otherwise.
Also try using a snapshot :).
Florin
This thread is actually three threads, am I right?
- 2.4 is unreliable ... presumably because USB 3 causes interferance ... possible fix to disable USB 3
- 2.4 is unreliabel ... possible fix something other than OpenWRt, something with more proprietieray bits and peices. (asides about using a different boot loader ... because? )
- the 5G behavior seems to had inconsistent behavior and packet drops.
- 5G isn't working at all ... a two suggestions to try a specific channel.
Ok then.
#1 - I don't have any USB devices attached, so I can't comment about #1.
#2. - no comment.
#3 - Having only now got any 5G working I can't say if #4 is a problem.
#4 - My problem..
Sure enough trying a specific chanel did help. I didn't try them all, but 48 works. Setting 40, 44, and 132 all work too - but it looks like they all map into up 48. Meanwhile 52, 100, 120, 134, and 135 didn't work. I didn't try all the channels.
In the US, where I'm at, there are regulatory rule about some of these channels. So this behavior might be a side effect of those.
So my thanks to: fvlaicu and netrix!
Is that consistent with other people's experience?
I might sound like a broken record, but have you tried the latest snapshot version?
Have a look at the differences between the wifi drivers that are in 18.06.1 and the latest snapshot:
I compared the hashes from the the 18.06.1 tag (https://github.com/openwrt/openwrt/blob/70255e3d624cd393612069aae0a859d1acbbeeae/package/kernel/mt76/Makefile#L12) and from the latest master commit https://github.com/openwrt/openwrt/blob/master/package/kernel/mt76/Makefile#L12
Oh, I think you'll have to try harder if you want to earn the broken record badge :). But yes, trying a snapshot is an option. On the other hand, I'm of the impression that it's all working now. Goal achieved, an all! Comming up next: wireguard 
And then there is this:
"snapshots are built daily, and that sets time limits to installing new packages with opkg. Due to kernel version checksums, you can only install “kmod” kernel modules and other kernel version dependent modules from the exactly same snapshot build. So, a few hours after flashing the firmware you may not be able to install new modules with opkg any more (as the next snapshot has been built into the download repo and has different checksums)."
So we shall see.
have a look at the kernel mods that are still in the repo:
https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/kmods/
Looks like a year worth of kmods are still kept.
Besides once you're on snapshot you can easily roll forward