Xiaomi Wifi Router 3G - 18.06.x / Wifi issues 2.4GHz + 5GHz

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:

  1. restarting the radio
  2. changing the channel, ssid, encryption.
  3. changing the number of wifi-iface.
  4. restoring a config from backup.
  5. 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?

  1. 2.4 is unreliable ... presumably because USB 3 causes interferance ... possible fix to disable USB 3
  2. 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? )
  3. the 5G behavior seems to had inconsistent behavior and packet drops.
  4. 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:

https://github.com/openwrt/mt76/compare/67803752363db5e81c7a74a9491a3041aa776284...3598046d01f1d7e9490ebf11e269323634702b05

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 :wink:

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 :wink:

Any news regarding the 2.4 Ghz problem? Its quite crazy that it persist for so long ... Is the newest mt76 version working correctly without sudden disconnects?

Not exactly Xiaomi Wifi Router 3G, but just tested on Newifi-D2 MT7621 box with the latest snapshot and also with 18.06 head snapshot (Thu Jan 17 03:36:18 2019) and with both ones the 2.4 GHz Wi-Fi stays in a working state ~10-20 seconds. On the client side I used Windows 10 and Intel(R) Centrino(R) Wireless-N 130 adapter.

do you mean the wifi drops after 20 seconds? Is openwrt working OK on that router? it looks decent for the price

The Newifi-D2 router itself feels pretty decent, but I fear OpenWRT MT7621 2.4 GHz Wi-Fi code has serious room for improvement. My issues Newifi-D2 are very similar to those in this thread. Xiaomi Wifi Router 3G is apparently based on MT7621 as well. Newifi-D2 2.4 GHz Wi-Fi is so flaky for me that I gave up for now and let another OpenWRT (GL-MT300N with MT7620N) box take care of it for my older 2.4 GHz only devices.

as this stupid 2.4GHz problem killed my nerves I decided to compile a version with the closed source drivers from "https://github.com/Nossiac/mtk-openwrt-feeds".
I contains:
-the most recent closed source 2.4GHz driver and is compiled with kernel-4.14.93
-latest open source mt76 5GHz driver
-plus a patch for IPv6 (https://bugs.openwrt.org/index.php?do=details&task_id=1763)

so far it works quite nicely 2.4GHz is not perfect but it works!

Feel free to use my build, feedback is welcome!

https://www.dropbox.com/s/ehbnvj94z5ecb9w/openwrt-ramips-mt7621-mir3g-squashfs-sysupgrade.bin?dl=0

Initially you have to load the driver and start the wifi interface manually, after that you can get it loaded via "/etc/rc.local". Check https://github.com/Nossiac/mtk-openwrt-feeds for further instructions or ask if you have problems.

To use those drivers you don't need to build a firmware as they are precompiled binaries working for that particular kernel.

True, but you need the particular kernel version and the most recent builds use 4.14.96. The newest precompiled kernel module is *.93, therefore I had to compile it by myself.
Or is there a repository with builds containing older kernel versions??

1 Like

Can you share the patch again?

There:

I recommend to regularly build the lastest snapshot including my patch (It's one time setup, just update git/repo and re-run make). Wifi drivers have gotten quite a bit better recently.
Please note that USB3 issues only arise when a USB3 device is plugged in !
Strangely, interferences are pretty bad even with an idle USB key.

2.4Ghz tends to stall quite a bit on my device. Reconnecting fixes it mostly, a reboot otherwise.
5Ghz is not that fast, but seems stable. Don't forget to set your country code, otherwise radar detection won't work, and there won't be any signal !

Also, consider using cron to reboot every night. Stability is greatly improved.
In scheduled tasks: "0 4 * * * reboot" to reboot at 4AM every night.

I ask since it seems mvebu is affected by this as well.

I wonder if there's a better way to do this...

So, has anyone tried 18.06.2 already? What's the general consensus?

Wifi 2.4GHz is stable. Using for several days without any problem. I did not encounter any problem with 18.06.2 but I did not performed any test just using as a main router.