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

I have a Newifi3 D2 and I have posted this topic about it here WiFi Problems 18.0.6.2 (MTK7621A D-Team Newifi D2)
it is a really good cheap router that I think would be capable of at least 50MB/s read and write as it has USB 3.0 and fast MiMo WiFi which does work quite well so far using Padavan
https://github.com/hanwckf/rt-n56u
or 18.06.1 OpenWRT. It is quite cheap on Ebay https://www.ebay.com/itm/401401806725

1 Like

Thanks. What exactly are Padavan and Pandorabox? I imagine that the Newifi3 would perform very similarly to the Mi3G. For me to import them, the prices are similar and the Mi3G looks sexier, so I'll probably go with that. :wink:

Padavan as far as I can tell is a fork of the AsusWRT firmware.
Pandorabox I am not sure of but I think has some relation to OpenWRT
Looks are not important for me usually but if the price is the same the sexier option sounds better :slight_smile:
Pandorabox looks like it was/is the chinese fork of OpenWRT for international devices
the url Openwrt.org.cn/ is found in some places but no longer working.

2 Likes

@lipek can you post the link to the github details you are referring too please?

just scroll up few posts
https://github.com/Nossiac/mtk-openwrt-feeds/issues/104

I'm noticing some issued with 2.4G only in 18.06.2.

5G works fine (however throughput isn't as high as it was on stock, max around 150mb when on stock it could be 3-500)

2.4G is a bit strange. Not noticing any disconnects but feels like it's frozen.

I wouldn't mind trying Pandora firmware but I've not had a good experience with it previously as it overwrites the stock bootloader and makes it somewhat more difficult to return to stock.

I am lucky with my router I can easily reset to the stock firmware, have not had any issues yet

Try the latest 18.06 snapshot and see if the problem persists.

Has the bug been fixed in the latest Snapshot?
Will the fixes be incuded in 18.06.3?

root@Router-BS:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.4'
DISTRIB_REVISION='r7808-ef686b7292'
DISTRIB_TARGET='ramips/mt7621'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 18.06.4 r7808-ef686b7292'
DISTRIB_TAINTS=''
root@Router-BS:~# cat /etc/openwrt_version
root@Router-BS:~# opkg list-installed |grep mt76
kmod-mt76-core - 4.14.131+2019-03-23-a5f5605f-1
kmod-mt7603 - 4.14.131+2019-03-23-a5f5605f-1
kmod-mt76x02-common - 4.14.131+2019-03-23-a5f5605f-1
kmod-mt76x2 - 4.14.131+2019-03-23-a5f5605f-1
kmod-mt76x2-common - 4.14.131+2019-03-23-a5f5605f-1

which mt76 version is inside 18.06.4?
I cant find that commit a5f5605f?

Installed latest snapshot "openwrt-18.06.4-ramips-mt7621-mir3g-squashfs-sysupgrade.tar"
but there is no wireless interface available under LuCI.

Commit hash references the mt76 repo, not the OpenWrt one.

Commit used in 18.06.04 is a5f5605f3246e65341cc11098e8168aff22a824b

I just installed Openwrt 18.06.4 on my MI3G and wanted to share my experience with WiFi so far.
After several reboots (after initial boot i had problems with WAN interface not connecting, seem to be gone now) i set both WiFis to auto-channel and the correct country-code, created an access point on each and everything seems to work fine.
I have noticed that not all of my (officially 5Ghz capable) devices - in particular 2 Nexus 7 2013 - are unable to find the 5Ghz network while all newer devices i have tested can see and connect to it without problems, coverage is also quite good compared to my TP-Link TL-WDR3600.
The Nexus 7 finds the 5Ghz network only if i set the channel to 36 manually.
I have even attached an USB-LTE modem and cannot find any problems with 2,4Ghz networks.

Auto-channel (ACS) is not a good idea in general (as it only selects the first legal channel, without anything more intelligent going on) and with mt76 in particular (which doesn't like this setting at all). Always configure a channel manually, trying to avoid overlap.

but this is wrong and not as intended: AUTO should search for a channel within the legally allowed range that is not croweded and provides best performance.

That is a misunderstanding, respectively wrong expectation, on your side - all it does is selecting the first available (as defined by the hardware constraints and legal limitations, not any more advanced channel survey) channel - not more, not less. While it obviously would be better if it would do a more comprehensive survey, but that's not what is actually implemented right now (patches welcome, I guess).

…and mt76 as currently in the repos doesn't support ACS yet at all (that's going to change, as the corresponding feature addition has been posted a couple of days ago, but it's not quite there right now)

Well, I guess the expectation is right, it is just that it is not implemented in that way currently. So I created this feature request to maybe raise awareness for it a bit and track the progress: https://bugs.openwrt.org/index.php?do=details&task_id=2437&order=id&sort=desc

Edit: Driver issue: https://github.com/openwrt/mt76/issues/306

Bugging the developers for a new feature won't speed up https://www.spinics.net/lists/linux-wireless/msg188625.html ("are we there yet?!").

…and no, that won't change the decision which channels to go with in the ACS case (namely the first possible one, without looking at anything else) either, as that's a policy decision done elsewhere.

As I said, I created it mainly to maybe raise awareness a bit and track the progress, as I stated above.

Nonetheless I would argue that it might help speeding things up, although the chances might be low.

Maybe I also misunderstood what is the place for implementation. Because from my understanding it looked not so much like a kernel issue, but rather an issue of correct implementation in OpenWrt (which is why I created an issue there) and in the mt76 drivers from OpenWrt (which is why I created an issue there). But you seem to have linked a mailing list related to kernel drivers. So maybe I misunderstood you in the first place and the problem resides somewhere else.