Re: RV340W freezes when using USB WAN

MattLewandowsky · ‎05-31-2020

I have an RV340W (firmware 1.0.03.17) and a USB730L. The combination works mostly fine, except that it freezes at random during periods of large transfers (sometimes "large" is defined as 10 megabytes in 5 seconds). There seems to be no rhyme or reason to the lockups (sometimes within moments of the USB connecting, sometimes days, but usually within an hour or two).

The symptoms as seen by a user are lack of WAN connectivity (both wired and wireless) and inability to obtain a DHCP lease. LAN switching still functions. The router's Web UI does not load, and the device is not pingable.

Is this a known issue (I know that 1.0.03.17 was supposed to fix similar issues)? I can't open a TAC case and I feel that as this is documented as a working scenario for the router that maybe I should be working on a warranty replacement?

I have tried factory resetting and spending all the time reconfiguring the router (I wish there was an easier way to handle configuring DHCP on VLANs...). But no luck comes of it.

And as the Console port is apparently non-functional, if this is a known issue that hardware replacement won't resolve, I might be forced to build a little device that checks every minute or so whether it can get a DHCP lease. If it cannot, it can physically switch the router off and back on. That, however, is very low on my list of desired outcomes...

mihail_ip · ‎06-01-2020

Hello Matt,

Can you see some errors specific to USB or WAN in the last part of the logs?

Regards

Mike

MattLewandowsky · ‎06-02-2020

I've not noted anything in the logs yet, no. I plan to turn on all of USB, remote syslog, and email logging in a few hours to see if something manages to log just before it fails. Cast a wide net and you might catch your prey, after all.

The only thing that strikes me so far is that the temperatures report higher in the UI when I'm using USB (but I don't know the device's thresholds so I don't know if they're "high"), and there's no real-time email alerts for temperature that I can see. But hopefully I'll see *some* email just as it fails which will narrow the syslog/USB log spelunking since that'll be the approximate "last known good" moment as the dongle will still be functional.

I had already wondered if somehow the switching functionality was involved (my network can get quite noisy with local traffic), but I have practically eliminated local traffic on the switch by moving everything to a switch connected to the RV340W (and letting that handle all my VLANs (most traffic is within 3 VLANs, so even that shouldn't affect things *too* much I'd hope). I've tried single port and 2-port LAG between the downstream switch and the RV340W to see if any changes were observed; there were none.

I'll report back on what happens with the logs, as logging was already something I was grumbling about. I had totally missed the USB saving checkbox and I didn't have remote syslog or a mailer ready for it yet. USB and mail are now ready and hopefully it'll syslog via LAN since I'm spinning up a dedicated VM to capture those logs.

I take it that no one reading has seen this particular behavior though. :(

Since someone is bound to ask at some point: my wired network consists of various IoT devices, media consumption devices (Rokus, TVs, Blu-Ray players, game consoles, etc.), and a mix of computer operating systems (ChromeOS, Windows NT 4 [I know... it's 2020...] through Windows 10/Server 2016, Linux, BSD, Solaris/Illumos, OS/2). The WiFi is basically just tablets and phones, with a couple of laptops when they're not near wired ports. While exotic, there shouldn't be any local traffic actually hitting the router anymore (since all wired traffic can't go higher than the ProCurve plugged into the RV340W's LAN 2 & 3 ports as LAG) which might give it fits since the only "exotic" system the wireless clients hit is a fully patched (physical, not virtual) ArcaOS (modern OS/2 distribution) box, and that's mostly HTTP and SMB anyhow.

MattLewandowsky · ‎06-02-2020

Well, I got syslog working... The last message emitted over the network prior to it dying was the normal network noise of:

Jun  2 11:23:19 rvw kernel [106726.252956] wl0: wlc_ampdu_resp_timeout: cleaning up resp tid 0 waiting forseq 0xe68 for 200 ms

I happened to be watching it when it died, and apparently this is the first time I watched it actually happen... At the same time that log message came across, all the lights went dark and it rebooted. When it finished, it was unreachable and not logging across the network. Since that message happens during normal operation, I sincerely doubt it's at all related to the issue.

I doubt email logging will help (which I can't get set up: it logs that authentication failed for SMTP, but a manual conversation with the server with the same credentials works... without knowing what it's sending, I can't troubleshoot it). And USB logging, I haven't figured out what to do to get it to actually log. I can't find docs on capacity, filesystem, etc. and the UI hasn't recognized any flash drive I've attached yet. But it's probably the only way I'll get its death throes and find out what it's doing when it's unresponsive. I might also be able to see what happens in the 96 seconds before it starts logging across the network.

I'm probably going to have to put email logging in the bucket of "features it claims to support, but which don't work properly" along with custom captive portal screens (without being able to specify a stylesheet, or even getting the one the default portal uses, the result is simply too ugly to show) and AD authentication (setting it up disables the "cisco" user, preventing login ever again).

But I refuse to give up on the dongle. Since I can't open a TAC case, how do I RMA this thing under warranty, if I can't figure out what's going wrong?

And, if any Cisco folks are reading this, *this* is why the Console port needs to be functional: I'm jumping through way too many hoops for trying to find things out which I would probably have no problem finding out over RS-232. The Web UI and the undocumented API simply do not help with a single thing when the device is 100% unresponsive to the network.

MattLewandowsky · ‎06-02-2020

By Wiresharking the WAN interface (I really shouldn't need to do this...), I discovered that SMTP logging is doomed to *never* work for me: it truncates the last 4 characters of my user name as the Web UI has a limit of 32 characters for the username. The SMTP username is a UUID (36 characters), so there's not much I can do about its length. The password encodes fine, as the Web UI allows 64 characters there. Perhaps allow 64 characters in each? Also there's no feedback that your username and password are truncated as they both have maxlength set on the field, so the JavaScript validation never runs; removing that attribute restriction provides visual feedback and a lack of Apply button...

I still cannot get USB logging working, and I can't figure out why.

So without a functional console port, I have no way of possibly discovering why this thing is dying.

I'm now even more upset at the device after going down the rabbit hole of trying to figure out why I get lockups with a supported USB dongle (and I am sad that generic RNDIS isn't supported now that I've seen RNDIS in the syslogs so much).

As far as I'm concerned, I wasted a few hundred dollars on this thing, at this point. Cisco apparently doesn't support it, it simply cannot do many of the things it is documented to do, and the warranty may as well be printed on tissue paper since it's impossible to actually figure out how to use its benefits. Very frustrating. And I was just discussing an upgrade to a RV345P from the hodgepodge of random gear they have, since he lacks failover, with someone I know who owns a few small hotels. After today's experiences, I'm going to have no choice but to tell him to stick with what he's got since it (mostly) works since I don't want to be the one who told him to buy a few thousand dollars' worth of lemon hardware. :(

USB failover was one of the key things that made me go with the RV340W rather than a competing device I was evaluating. It's unacceptable that so many of its documented features (including USB failover) don't work.

MattLewandowsky · ‎06-02-2020

Well, I can't open a TAC case for this thing, there's no warranty service for it, I've been fighting with the seller to take it back, and my updates to this thread with the laundry list of *other* issues I've found while investigating the issue have disappeared. I can no longer, in good faith, continue to recommend the RV series to anyone, and I'm stuck with an multi-hundred-dollar brick that can't do many of the things that it's documented to do, including email. I'm very unhappy with Cisco right now.