Hello! If not ask too much, could you explain the process? The part of loading the driver until I understood, but what about that microcode part? How do you configure it?
I'm thinking of getting one of these devices to use as a WAP. I need excellent 5GHz throughput. I can achieve 50MB/s read and write to my NAS using my laptop or phone with my R7000 with dd-wrt. Would I be likely to achieve these speeds on the Xiaomi if it was running a recent snapshot?
I have a Newifi3 D2 and I have posted this topic about it here WiFi Problems 188.8.131.52 (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
or 18.06.1 OpenWRT. It is quite cheap on Ebay https://www.ebay.com/itm/401401806725
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.
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
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.
@lipek can you post the link to the github details you are referring too please?
just scroll up few posts
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