Understood!
Let me re-install it and see if its getting resolved or not.
BTW, I'm using mine as an AP exclusively, that could explain why I haven't encountered the same issue related to WAN connections.
No luck. I have flashed the latest using the link you have provided by tftp but still getting frequent packet drops.
quest 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
64 bytes from 172.217.163.174: icmp_seq=43 ttl=49 time=2066.881 ms
64 bytes from 172.217.163.174: icmp_seq=44 ttl=49 time=1064.670 ms
64 bytes from 172.217.163.174: icmp_seq=45 ttl=49 time=64.515 ms
64 bytes from 172.217.163.174: icmp_seq=46 ttl=49 time=46.401 ms
64 bytes from 172.217.163.174: icmp_seq=47 ttl=49 time=46.297 ms
64 bytes from 172.217.163.174: icmp_seq=48 ttl=49 time=46.365 ms
64 bytes from 172.217.163.174: icmp_seq=49 ttl=49 time=46.357 ms
64 bytes from 172.217.163.174: icmp_seq=50 ttl=49 time=46.217 ms
64 bytes from 172.217.163.174: icmp_seq=51 ttl=49 time=46.341 ms
64 bytes from 172.217.163.174: icmp_seq=52 ttl=49 time=46.298 ms
64 bytes from 172.217.163.174: icmp_seq=53 ttl=49 time=46.439 ms
Request timeout for icmp_seq 56
Request timeout for icmp_seq 57
Request timeout for icmp_seq 58
Request timeout for icmp_seq 59
Any help?
@Santosh Are you on 18.06.2? If so, you can try installing these packages that include a possible fix (I can pastebin the patch if you'd like, has been provided by the developer).
https://volatilesystems.org/dl/lede/mt76/
These packages are built against the 18.06.2 codebase, you should be able to install them on vanilla 18.06.2 setups.
Edit: if you have no means to recover your hardware, do NOT use these drivers. They do work for me on a mt7621 platform (DIR-860L rev. B1).
1 Like
Thank you for your help.
I performed factory reset and then installed all those packages but now router is not coming up, it keeps on restarting.
You're still able to U-Boot recover it, right?
@Santosh if your device allows it boot into safe mode and load the driver manually, see if it's the wireless drivers causing problems.
yep, flashed LEDE again using tftp and now back to same problem (frequent packet drops)
I am not sure if this device has any safe boot, I tried the combination (power on and wps) which is letting me boot from recovery. Is there any way to start in safe mode?
That's safe mode afaik. That doesn't mount /overlay so you are back to default packages & settings. From there, you could mount /overlay, remove the default packages, install the newer mt76 ones and modprobe them, and see if that breaks your build.
LEDE is 17.01.x BTW, OpenWrt is 18.06.
If I am not wrong then that's U-boot and kernel doesn't have ssh so I am not sure how can interact with it, is there anyway to connect to it so that I can mount and test?
On the stripped down version (Snapshot) when i tried installing kmod-mt76x2 packages from the link mentioned by you, I got several dependencies error. For few of the package (common, core) I tried it installing dependent pack but still having many errors therefore I dropped it. I think i need to compile it which will require lot if time and I don't have much knowledge
Actually, I have tried all the possible builds - Snapshot, LEDE, full firmware with LUCI, few of them compiled by @julianocs but unfortunately none of them worked for me 
I'm unable to reproduce your problem. I loaded custom-built snapshot r9071-27be78ef46 some weeks ago from master. 18.06.2 was released after this snapshot.
My WR841 v13 (192.168.2.1) hangs from a second one, so by pinging 192.168.1.1 it has to go trough WAN interface. After more than 1000 pings got 0 timeouts. My laptop connects to WR841 v13 via wifi, with good signal strength
?
I have tried the snaphot version from this weekend and it is not stable for WiFi. (https://downloads.openwrt.org/snapshots/targets/ramips/). This contains the Feb 3 commits to mt76.
The snapshot version from about two weeks ago was a lot more stable.
@twinkleLED Can you be more specific about the issues you're experiencing? Packet loss, connection loss, timeouts?
I see:
- connection loss (e.g.already open ssh connections being broken)
- dropped ping packets (far more often than the normal low background)
- unable to open web pages (not clear, but DNS not working is one issue)
- unable to open ssh connection
I then will have some time when things seem to work fine.
Sorry for late reply, I got busy in office work and was doing some more testing.
First off all I have installed the TP-Link original firmware to confirm if there is any hardware issue, but on 3 days usage I didn't observe any packet drop and worked as expected.
Then I have flashed OpenWrt 4.14.98 with SNAPSHOT, r9293-e3311cb on 18.06.2 branch and as you might have guessed it came back to original packet drop issue.
One more I would like to mention is, earlier when I was using 18.06.1 then it was working but sometimes it will simply disconnect all WiFi clients so I wrote a script to restart every time client count was zero. But currently its not even working for me.
Below is the image from speedtest.net
Could you please give me the link where you dont see any issue? (older version)
I can relate few issue with my router too but SSH connection never lost in my case, but if I ping google.com then in every 15 icmp request next 5 packets will be dropped and then again network will be restored.
Sorry, all I can say is -as before- that I'm using custom build of r9071-27be78ef46
Yesterday I noticed (as reported by twinkleLED) that open of web pages was very slow, DNS looked as stalled but then there was not ping at all. So I guess connections were lost. After restart, i got connection loss again in very short time. Before that, I have been working with that router for more than a week without noticing any problems.
It does seem the problems happen intensely for a period, and then seemingly go away for a while.
I'm using snapshot r9258-420376a.
I think that the only issue that I can relate to is webpages not opening or taking too long in some cases (as if the DNS took more than the average time to respond). Other than that, it has worked reasonably well. No ping drops (in a 1000 ping sample), no ssh connection drop or problem establishing said connection.
To be fair, all the things that work well are using a wired connection, the webpage load lag or failure happens sometimes using wifi. Also, I'm not using the device as a router, rather as an AP.
Here's an example of a 48h ICMP monitoring session to a WiFi connected printer:
