02-09-2019 03:46 PM
Looking forward to resolution.
02-09-2019 03:49 PM
03-18-2019 03:28 PM
I would like to see the severity of this issue bumped from moderate to something more serious. Needing to reboot a router to restore wireless functionality is not a moderate issue. This is a wireless router, so I would say that most users have bought this model because of it's wireless capabilities, and frequent loss of that functionality is a serious issue.
What is worse: The suggested workaround of a reboot implies that also the LAN-connected users loose their networking capabilities.
I need to reboot the router because of this issue every other day on average and sometimes several times per day, meaning that connected users loose their connections for about 3 minutes at minimum. And I'm doing this already for months on ends. It is about time this issue gets resolved.
05-01-2019 02:50 AM
Workaround found - disable 5Gz wifi.
this allows client to connect to wifi on 2.4Gz .
seems that 5Gz connectivity is faulty and clients connections "freeze" on 5Gz without any throughput.
above workaround - still it dos not resolve log entries like these, which appear almost every second.:
warning
kern
kernel: [3114778.726982] ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726974] ampdu_dbg: again1 ifsstat 0xaf nav_stat 0x0
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726966] ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 7 0 0 0 0 ifs_boff 0
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726928] ampdu_dbg: txall 222 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726921] ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726914] ampdu_dbg: ifsstat 0xaf nav_stat 0x0 txop 83395
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726904] ampdu_dbg: wl0.0 dead_cnt 2 tx_in_transit 1 fifordy 0x0 frmcnt 0x400 fifosel 0x7
2019-May-01, 09:28:50 UTC
warning
kern
kernel: [3114778.726882] ampdu_dbg: wl0.0 1c:36:bb:85:d2:04 scb:bdbd8000 tid:0
2019-May-01, 09:27:45 UTC
warning
kern
kernel: [3114714.056909] ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
03-23-2020 07:27 AM
Issue Still present:
Device Model: | RV340W |
PID VID: | RV340W-E-K9 V02 |
Current Firmware Version: | 1.0.03.16 |
Last Updated: | 2019-Aug-31, 08:33:39 UTC |
Last Version Available on Cisco.com: | 1.0.03.16 |
Last Checked: | 2020-Mar-18, 15:43:02 UTC |
2.4 Ghz devices which stay connected long time occasionally will get access totally frozen. while 2.4Ghz devices that come in and out periodically - will have a normal connection.
If 2.4Ghz device that gets access frozen will restart - access is still connected-but-frozen.
Only restart of 2.4Ghz radio in RV340W or full power-cycle will reconnect and provide internet to 2.4Ghz devices.
11-20-2019 10:26 AM
I am having this problem with 3 routers in 3 different locations with the latest firmware 1.0.03.16. Its getting REAL old resetting the router. Very unacceptable!!!
11-21-2019 09:27 AM
I also tried the 5Ghz disable that was mentioned in a prior post above. It did not make a difference in my situation. It's very frustrating! One of the routers has been rebooted 6 times in 24 hours. I chose this router for the VPN capabilities (site to site with high speed up/download) which works really well. The WiFi is just a big let down, I do not think its a hardware issue either. My bet is on the firmware.
03-15-2020 06:24 AM - edited 03-15-2020 06:54 AM
Same issue here with 1.0.03.16. and we have done a reset to factory settings. We have 2 units in other locations being used as access points and one at our location which is our only router with no other access points. For us, it's not 5GHz having issues, it's more frequently random devices using the 2.4GHz that are affected. They remain connected to the SSID, but suddenly have "no internet connectivity" while others on 2.4GHz and 5GHz as well as wired clients are still fine. One goes down than a random time later, another will go, then another. Until someone complains then we ask and find yes, others just ignored it (phone went to cell, turned the game off, etc...) There is no explanation on the devices like an update happening (it could be a Windows device, a phone, a game system, a printer), and every single time what resolves it is to disable and re-enable the wireless radio on the router (via the button on rear). A full reboot is not needed. We need to find a way to do this remotely.
03-15-2020 06:52 AM
I am very disappointed to see the bug status is "terminated - No release planned to fix this bug"
The 2 devices at client's sites were a test; we had intended to place the same at the client's 5 other locations. If it will never be fixed, unless we can quickly find a way to automate resetting the radio, we'll be looking at other vendors' produtcs.
11-21-2019 03:40 PM
I struggled with this issue for more than a year, and recently updated my router to 1.0.03.16. I ran this firmware for some weeks, and decided to poke around the settings some more and re-enable 5GHz. At first things seems even worse: My setting changes were not applied anymore at all. In the release notes there is an advice to RESET to FACTORY settings when upgrading to this firmware, which is a pain since all personalized configuration has to be re-done.
But I decided to spend the afternoon doing just that, and in the few weeks since, the 5GHz seems to be working. At the moment I have 1 PC permanently on 5GHz no issues, and a cell-phone, which I intermittently use on 5GHz. I can not say that the phone connects fast (the DHCP lookup seems slow), but it hasn't failed yet.
I would like to hear if the other people who have the same troubles after upgrading to 1.0.03.16 and doing the factory RESET see the same improvement, and the same slow connects that I now see.
I still consider 1.0.03.16 an improvement for me, since I don't have to through a power-on cycle every other day or so.
01-22-2020 09:34 PM - edited 01-22-2020 09:51 PM
interestingly enough...for completely different reasons, i rolled back all the way to fw 1.0.00.33, and i have been running 9 days straight now without any wireless issues and not a single reboot required. currently i have all updates turned off, at least for me, fw 1.0.00.33 is stable. 1.0.00.33 has its share of problems for sure, but wifi stability is not one of them. prior to this, i was rebooting once or twice a day.
i've only had this router since late december 2019, but imo wireless functions on this router cannot be used in a production environment and cisco should recall these routers and just refund everyone's money. there is no way you could put this unit into production in a business environment where wifi SLA is critical. this particular model should not be sold to SMBs who typically need a friendly solution that's accessible to the less technically capable crowd. i'm just playing around at home, but the wife wasn't happy with the constant reboots.
reading through all the release notes for firmware versions, i'm convinced that wireless instability was introduced by cisco in one of their prior firmware releases, my guess is 1.0.02.16 when the ux was changed and a lot of the "plumbing" was reworked. since this issue has been acknowledged by cisco but forgotten/ignored in current release notes, i would not recommend a cisco RV series router to anyone. the workaround solution to "reboot the router" in the release notes is just a slap in the face.
02-27-2020 04:25 PM
I too am having the same problems... One thing I've also noticed is the router seems to be running hot to the touch... Don't know if this is related to the wifi dropping connections. Shouldn't be running that hot as the vents are not blocked and the office it's in is around 78 degrees.
04-13-2020 05:49 AM
I have huge respect for Cisco product, but since I bought this router RV340W almost two years ago I have the issue from day one. Now, I am on 1.0.03.17 and have tried all monkey tricks but it still has issues, and I was waiting for the next firmware, next firmware but now I believe it is a hardware issue as they made faulty device. Thing happens these days with any company as they keep rushing making products without proper testing, I would suggest that Cisco should recall this product and or look into hardware chipset issue rather than firmware.
Now my $15 used technicolor router is 10x times faster and working perfectly fine, at least my mom Whatsapp does not get disconnects. I am thinking to return this product.
09-23-2020 02:53 PM
Yeah exactly. Cisco, can you just fix the wireless problem? Literally all of us have this same issue, and the response is “reboot” - wireless routers from 15 years ago are more stable.
Please fix it
08-27-2020 01:12 PM
I have had the same issue since I bought my router - now 2 years of reboots after reboots because the WiFi is so unstable. One thing I found is that rather than a reboot I can switch of the radios and back on and the problem goes away for a day or so.
In terms of preventing the problem what I've figured is the more you use it the greater the probability of it going wrong.
This is really annoying and a fundamental issue.
This is the third model of RV routers and all seem to have really buggy firmware.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide