Perhaps I'm missing something? Checking https://github.com/openwrt/mt76 I can see just one change, namely "mt7603: implement support for SMPS", and, by doing git pull right now I can't see any changes related to mt76.
I'm not really used to follow development so closely, usually I work with the stable branch to get images<4MB and avoid master. So I wonder were you get those informations about latest commits. Could you elaborate further about knowing when the commits are done?
After edit the MakeFile, you have to run the command "git pull" to update.
You will not see anything related to mt76 , but the new driver will be downloaded and compiled.
I've tried stable FW from 17 January, it's the worst I've seen so far. WiFi is highly unstable, and when it magically connects it just takes a few steps away from the router for it to not be able to connect any longer, the stable branch is complete trash. Wireless authentication problems are rampant:
Thu Aug 16 08:04:21 2018 daemon.info hostapd: wlan0: STA 0c:d7:46:d8:3a:dd IEEE 802.11: disassociated
Thu Aug 16 08:04:21 2018 daemon.notice hostapd: wlan0: STA d8:32:e3:9f:9c:81 IEEE 802.11: did not acknowledge authentication response
Thu Aug 16 08:04:22 2018 daemon.info hostapd: wlan0: STA 0c:d7:46:d8:3a:dd IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Aug 16 08:04:23 2018 daemon.notice hostapd: wlan0: STA 70:28:8b:bc:bc:fe IEEE 802.11: did not acknowledge authentication response
Thu Aug 16 08:04:27 2018 daemon.info hostapd: wlan0: STA 44:6e:e5:36:59:37 IEEE 802.11: disassociated due to inactivity
Thu Aug 16 08:04:28 2018 daemon.info hostapd: wlan0: STA 44:6e:e5:36:59:37 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Aug 16 08:04:31 2018 daemon.notice hostapd: wlan0: STA 74:4a:a4:fa:ad:f8 IEEE 802.11: did not acknowledge authentication response
Thu Aug 16 08:04:35 2018 daemon.notice hostapd: wlan0: STA e4:fb:8f:1c:d4:13 IEEE 802.11: did not acknowledge authentication response
@julianocs Thanks for the heads-up, the snapshot from 29th was pretty decent already - and I was particularly ranting about the fact that the recent "stable" firmware from the 17th was actually the most unstable crap I've tried so far on this router.
In any case, I'll make sure to update it with the latest snapshot since so much effort is being put into stabilizing the driver. Btw, I was keeping an eye on the Github page for mt76, yet the last commit there is from 3 days ago. I'm pretty sure someone already asked you this, but I have to anyway: where can you spot the latest commits and those then being merged into the snapshot branch?
Just tested now with sysupgrade.bin and its very bad for me. Every minute its dropping the packet, few website are even failing to load (speedtest.net). I have v9 router with openwrt and thats working flawless, not sure what I am doing wrong.
Anybody else having this issue?
Ping result:
PING google.com (216.58.200.142): 56 data bytes
64 bytes from 216.58.200.142: icmp_seq=0 ttl=49 time=42.748 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
64 bytes from 216.58.200.142: icmp_seq=27 ttl=49 time=1007.432 ms
64 bytes from 216.58.200.142: icmp_seq=28 ttl=49 time=42.376 ms
64 bytes from 216.58.200.142: icmp_seq=29 ttl=49 time=44.239 ms
64 bytes from 216.58.200.142: icmp_seq=30 ttl=49 time=41.850 ms
64 bytes from 216.58.200.142: icmp_seq=31 ttl=49 time=41.768 ms
64 bytes from 216.58.200.142: icmp_seq=32 ttl=49 time=42.523 ms
64 bytes from 216.58.200.142: icmp_seq=33 ttl=49 time=42.752 ms
64 bytes from 216.58.200.142: icmp_seq=34 ttl=49 time=43.078 ms
64 bytes from 216.58.200.142: icmp_seq=35 ttl=49 time=42.775 ms
64 bytes from 216.58.200.142: icmp_seq=36 ttl=49 time=42.731 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
Request timeout for icmp_seq 44
@Santosh I had some issues with it at first, mostly on wi-fi though, but I can't say I have the issue you're describing. There are still some quirks here and there, sometimes it starts lagging or a client will need to disconnect/reconnect to get going, but everything has improved since a few months ago. I also had lots of problems on the original firmware, main reason why I went for OpenWRT with v13. I also have a v10 (I think it's a v10, could be a v9 - unsure atm) and it works much better for sure. Anyway, there may be a conflict with the upgraded components so I advise you to reflash from scratch with the latest snapshot, give it another try afterwards.