Linksys MR8300, OpenWrt 22.03.0-rc4, USB port-powered storage devices not working

Hi,

Due to my previous OpenWrt router having become a bit outdated, I got myself a shiny new Linksys MR8300 V1.1, which I am in general quite happy with.
I opted directly for the lastest available release candidate, OpenWrt 22.03.0-rc4, and it's up and running.

There is just one annoying issue with the USB port.
I'd like to use the MR8300 as a router with built-in NAS functionality, by installing Samba server on it and plugging a flash drive (thumb drive) into its USB port.

However, when running OpenWrt the router won't register any of my flash drives.
I have tried four different flash drives covering the whole range from superfast Sandisk USB3 to cheap no-name USB2.

Fearing the worst I switched back to the Linksys software on the other partition and all four drives work absolutely perfect there.

Back to OpenWrt I started experimenting with a USB 3.0 switch. Here is what I've found.

  • USB flash drive plugged directly into MR8300's USB port -> none of 4 drives work
  • USB switch plugged into MR8300's USB port and USB flash drive plugged into switch -> none of 4 drives work
  • USB switch plugged into MR8300's USB port, USB flash drive plugged into switch and external 5V power supply connected to the USB switch -> all 4 drives work flawlessly

I further noticed that once the USB flash drives are registered by OpenWrt I can unplug the external power supply from the USB switch and everything still keeps working fine. (that is, until I power cycle or reboot the MR8300)

To troubleshoot this anomaly I plugged an adjustable load into the MR8300's USB port to test if there may be a issue with the USB port not supplying sufficient power. I turned the current up to 500 mA (0,5 A), which the USB port successfully managed to supply.

Next I used a so-called "USB Safety Tester" that can be plugged in between an USB port and an USB device to measure how much current my USB flash drives draw. They were all within a range of 20 mA to 60 mA, which obviously is just a tiny fraction of the power the USB port is capable of supplying.

However, during that test I noticed that the USB tester would restart right after I've plugged a flash drive into the USB tester's USB port. That "USB tester" doesn't read any bus signals, it just hooks itself up to the 5VDC USB power rail to measure voltage and current and itself operates of the USB port's power. If it restarts it can only mean that power was interrupted for a very short moment.

So it kind of appears to me as if OpenWrt was cutting the USB power for maybe a few milliseconds right at the moment the USB drive negotiates the connection with the router's USB port.
Plugging a powered USB switch in between the router's USB port and the USB drive basically helps to bridge that power interruption.

Has anyone else experienced such issues with the MR8300's USB port when using OpenWrt?

In case someone else here has the same router, but no problems with the detection of USB thumb drives, then can you please let me know which version of OpenWrt you are using or if you maybe have installed a special driver package or whatever?

So far the workaround with the powered USB switch has been working stable, but I would like to get rid of the powered switch, if possible.

2 Likes

+1 for the very good analysis with electronic load and USB tester.

Do you observe the same issue with 21.02.x and master snapshot?
Is there anything useful in the logs?

Thank you for your reply.

I haven't tried any other OpenWrt version than the one I mentioned. Actually I was kind of hoping someone might be able to recommend a version that doesn't have the issue with the USB port. :slightly_smiling_face:

Here is a link to a short video that shows an oscilloscope trace of the USB port's 5VDC in parallel with the output of "logread && logread -f".
(btw, is it possible to get a more detailled log with another command?)

The USB drive was plugged into the USB port at around 0:28.
"https://youtu.be/U8Yjz6G-yiM"

Image of the signal trace with adjusted time scale:
"https://ibb.co/5xk8WL4"

which oscilloscope was used to measure this signal?
Try the OpenWrt 21.02.3 version.
I am using this version and it is working fine with sandisk USB.

Thanks! When I get a chance I will try OpenWrt 21.02.3.

The PC oscilloscope I used is called OWON VDS1022I.

Ok, Yesterday I finally got to do a bit more testing. First tried version 22.03.0-rc5 and then version 21.01.3.

Version 22.03.0-rc5 behaves identical to 22.03.0-rc4.

Unfortunatelly, with version 21.01.3 I also haven't been able to get the USB thumb drives to work without external 5V power.
However, one noticable difference is that, while with the 22.03.0-rc4/5 versions the USB drives always disconnect ("usb 2-1: USB disconnect, device number") immediately after the "[sda] Attached SCSI removable disk" message appears (via logread), with version 21.01.3 the disconnects happen somewhere between 20 and 100 seconds after the "[sda] Attached SCSI removable disk" message.

I didn't have the time to setup my oscilloscope to check for 5V dropouts.

Sun Jul 17 20:43:14 2022 user.info : luci: accepted login on / for root from 192.168.1.129
Sun Jul 17 20:46:25 2022 authpriv.info dropbear[2768]: Child connection from 192.168.1.129:57405
Sun Jul 17 20:46:31 2022 authpriv.notice dropbear[2768]: Auth succeeded with blank password for 'root' from 192.168.1.129:57405
Sun Jul 17 20:46:58 2022 kern.info kernel: [   82.140614] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
Sun Jul 17 20:46:59 2022 kern.info kernel: [   82.177710] usb-storage 2-1:1.0: USB Mass Storage device detected
Sun Jul 17 20:46:59 2022 kern.info kernel: [   82.179240] scsi host0: usb-storage 2-1:1.0
Sun Jul 17 20:47:00 2022 kern.notice kernel: [   83.195236] scsi 0:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS37 PQ: 0 ANSI: 6
Sun Jul 17 20:47:00 2022 kern.notice kernel: [   83.557909] sd 0:0:0:0: [sda] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
Sun Jul 17 20:47:00 2022 kern.notice kernel: [   83.561181] sd 0:0:0:0: [sda] Write Protect is off
Sun Jul 17 20:47:00 2022 kern.debug kernel: [   83.564522] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
Sun Jul 17 20:47:00 2022 kern.notice kernel: [   83.565843] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Sun Jul 17 20:47:00 2022 kern.info kernel: [   83.577391]  sda: sda1
Sun Jul 17 20:47:00 2022 kern.notice kernel: [   83.583716] sd 0:0:0:0: [sda] Attached SCSI removable disk
Sun Jul 17 20:48:40 2022 kern.info kernel: [  183.558152] usb 2-1: USB disconnect, device number 2
Sun Jul 17 20:48:41 2022 kern.info kernel: [  184.241029] usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
Sun Jul 17 20:48:41 2022 kern.info kernel: [  184.288829] usb-storage 2-1:1.0: USB Mass Storage device detected
Sun Jul 17 20:48:41 2022 kern.info kernel: [  184.290208] scsi host0: usb-storage 2-1:1.0
Sun Jul 17 20:48:42 2022 kern.notice kernel: [  185.346979] scsi 0:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS37 PQ: 0 ANSI: 6
Sun Jul 17 20:48:42 2022 kern.notice kernel: [  185.712026] sd 0:0:0:0: [sda] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
Sun Jul 17 20:48:42 2022 kern.notice kernel: [  185.716342] sd 0:0:0:0: [sda] Write Protect is off
Sun Jul 17 20:48:42 2022 kern.debug kernel: [  185.718787] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
Sun Jul 17 20:48:42 2022 kern.notice kernel: [  185.722689] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Sun Jul 17 20:48:42 2022 kern.info kernel: [  185.728624]  sda: sda1
Sun Jul 17 20:48:42 2022 kern.notice kernel: [  185.736424] sd 0:0:0:0: [sda] Attached SCSI removable disk
Sun Jul 17 20:49:37 2022 kern.info kernel: [  240.591509] usb 2-1: USB disconnect, device number 3
Sun Jul 17 20:49:37 2022 kern.info kernel: [  241.124325] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci-hcd
Sun Jul 17 20:49:38 2022 kern.info kernel: [  241.171442] usb-storage 2-1:1.0: USB Mass Storage device detected
Sun Jul 17 20:49:38 2022 kern.info kernel: [  241.173987] scsi host0: usb-storage 2-1:1.0
Sun Jul 17 20:49:39 2022 kern.notice kernel: [  242.218300] scsi 0:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS37 PQ: 0 ANSI: 6
Sun Jul 17 20:49:39 2022 kern.notice kernel: [  242.585311] sd 0:0:0:0: [sda] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
Sun Jul 17 20:49:39 2022 kern.notice kernel: [  242.589278] sd 0:0:0:0: [sda] Write Protect is off
Sun Jul 17 20:49:39 2022 kern.debug kernel: [  242.592537] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
Sun Jul 17 20:49:39 2022 kern.notice kernel: [  242.595504] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Sun Jul 17 20:49:39 2022 kern.info kernel: [  242.603627]  sda: sda1
Sun Jul 17 20:49:39 2022 kern.notice kernel: [  242.609648] sd 0:0:0:0: [sda] Attached SCSI removable disk
Sun Jul 17 20:50:02 2022 kern.info kernel: [  265.627154] usb 2-1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
Sun Jul 17 20:50:02 2022 kern.info kernel: [  266.075521] usb 2-1: USB disconnect, device number 4
Sun Jul 17 20:50:03 2022 kern.info kernel: [  266.681906] usb 2-1: new SuperSpeed Gen 1 USB device number 5 using xhci-hcd
Sun Jul 17 20:50:03 2022 kern.info kernel: [  266.718817] usb-storage 2-1:1.0: USB Mass Storage device detected
Sun Jul 17 20:50:03 2022 kern.info kernel: [  266.720057] scsi host0: usb-storage 2-1:1.0
Sun Jul 17 20:50:04 2022 kern.notice kernel: [  267.734474] scsi 0:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS37 PQ: 0 ANSI: 6
Sun Jul 17 20:50:04 2022 kern.notice kernel: [  268.086839] sd 0:0:0:0: [sda] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
Sun Jul 17 20:50:04 2022 kern.notice kernel: [  268.087723] sd 0:0:0:0: [sda] Write Protect is off
Sun Jul 17 20:50:04 2022 kern.debug kernel: [  268.093365] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
Sun Jul 17 20:50:04 2022 kern.notice kernel: [  268.094253] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Sun Jul 17 20:50:04 2022 kern.info kernel: [  268.103124]  sda: sda1
Sun Jul 17 20:50:04 2022 kern.notice kernel: [  268.110688] sd 0:0:0:0: [sda] Attached SCSI removable disk
Sun Jul 17 20:50:29 2022 kern.info kernel: [  292.596470] usb 2-1: reset SuperSpeed Gen 1 USB device number 5 using xhci-hcd
Sun Jul 17 20:50:30 2022 kern.info kernel: [  293.492031] usb 2-1: USB disconnect, device number 5
Sun Jul 17 20:50:30 2022 kern.info kernel: [  294.040734] usb 2-1: new SuperSpeed Gen 1 USB device number 6 using xhci-hcd
Sun Jul 17 20:50:30 2022 kern.info kernel: [  294.091313] usb-storage 2-1:1.0: USB Mass Storage device detected
Sun Jul 17 20:50:30 2022 kern.info kernel: [  294.093387] scsi host0: usb-storage 2-1:1.0
Sun Jul 17 20:50:32 2022 kern.notice kernel: [  295.171730] scsi 0:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS37 PQ: 0 ANSI: 6

I have now switched back to OpenWrt 22.03.0-rc5 and will live with a hardware workaround for the time being, until this finally might be fixed in the software.
I've been able to simplify the hardware workaround down to a 470µF capacitor and 10Ω resistor that I soldered between the USB port's 5VDC and Ground (using the breakout cable I originally used for connecting the oscilloscope). This capacitor marginally allows the USB thumb drive to be powered through the USB power interruptions.

https://ibb.co/rHDJfqv

Thu Jul 21 17:32:55 2022 daemon.notice netifd: wwan (2488): udhcpc: sending renew to server 192.168.23.57
Thu Jul 21 17:32:55 2022 daemon.notice netifd: wwan (2488): udhcpc: lease of 192.168.23.147 obtained from 192.168.23.57, lease time 3599
Thu Jul 21 17:55:48 2022 kern.info kernel: [ 3210.523144] usb 1-1: new high-speed USB device number 75 using xhci-hcd
Thu Jul 21 17:55:48 2022 kern.info kernel: [ 3210.716340] usb-storage 1-1:1.0: USB Mass Storage device detected
Thu Jul 21 17:55:48 2022 kern.info kernel: [ 3210.726568] scsi host0: usb-storage 1-1:1.0
Thu Jul 21 17:55:49 2022 kern.notice kernel: [ 3211.807422] scsi 0:0:0:0: Direct-Access     CBM      Flash Disk       5.00 PQ: 0 ANSI: 2
Thu Jul 21 17:55:49 2022 kern.notice kernel: [ 3211.811409] sd 0:0:0:0: [sda] 4114432 512-byte logical blocks: (2.11 GB/1.96 GiB)
Thu Jul 21 17:55:49 2022 kern.notice kernel: [ 3211.819327] sd 0:0:0:0: [sda] Write Protect is off
Thu Jul 21 17:55:49 2022 kern.debug kernel: [ 3211.822033] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
Thu Jul 21 17:55:49 2022 kern.err kernel: [ 3211.824180] sd 0:0:0:0: [sda] No Caching mode page found
Thu Jul 21 17:55:49 2022 kern.err kernel: [ 3211.826697] sd 0:0:0:0: [sda] Assuming drive cache: write through
Thu Jul 21 17:55:49 2022 kern.info kernel: [ 3211.835954]  sda: sda1
Thu Jul 21 17:55:49 2022 kern.notice kernel: [ 3211.840194] sd 0:0:0:0: [sda] Attached SCSI removable disk
Thu Jul 21 17:55:49 2022 kern.warn kernel: [ 3212.024688] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Thu Jul 21 18:02:54 2022 daemon.notice netifd: wwan (2488): udhcpc: sending renew to server 192.168.23.57
Thu Jul 21 18:02:54 2022 daemon.notice netifd: wwan (2488): udhcpc: lease of 192.168.23.147 obtained from 192.168.23.57, lease time 3599

I am facing a similar issue on 21.02.3.r16554. I have ntfs formatted sandisk usb stick 128mb and i works fine as a network harddrive. Only issue is that the function for shut down the power on the usb port is not working. Normally when i use this "luci-app-hd-idle" it will shut down poer to the usb device after the time that you put in. But it is constantly powered on.
But if i connect my 2 tb ssd harddrive it doesn´t even detect the drive. the power is on and it doesn´t shut down for the drive, it just dont detect it. I have tried to use a usb hub with external power but openwrt doesn´t detect the drive.... My old linksys wrt1900acs is working witout any issues with the same drive and "luci-app-hd-idle" is also working fine. But i just can´t figure out why mr8300 can´t detect my ssd drive.
Edit: " i just tried a 2 tb non ssd, harddrive and it works perfect, also the spin down timer are working.

I have the same device, MR8300 and I can confirm this bug also.

I use it with 21.02.3, and neither USB2 flash drives neither USB3 2,5" external HDD enclosures don't work in the USB3 port.

What works is using 3,5" external HDD enclosures with a separate power supply.

I can't recall exactly, but I think I've read somewhere that maybe the USB3 controller is mulitplexed with the Qualcomm Atheros QCA8075 switch inside the device?

Or maybe this is related to the problem - HW manufacturers have to adjust USB3 ports against 2.4Ghz Wifi interference so there can be some proprietary modifications in the original Linksys firmware?

https://uk.pcmag.com/networking/13179/wireless-witch-the-truth-about-usb-30-and-wi-fi-interference

Hello,

I just installed OpenWrt on an MR8300 and I have the same problem. I've been struggling with an SSD for 2 days thinking of a drive or partition problem... It appears "not present" in the mount point. I did a test with an old hard drive that works fine.

That article is about RFI from USB3 compromising the 2.4Ghz WiFi performance. I doubt it has anything to do with the problem described here. RFI is something that any electric appliance/gadget manufacturer has to deal with (minimizing RFI generation or being impacted with).

Did you mean that the old hard drive works fine with MR8300? I am interested in the problem because I have my eyes on an MR8300 unit to run OpenWrt.

Hi all
I've just set up a newly bought Linksys MR8300 and I'm having the same issue. The disk I have worked fine with my old BT HomeHub device running OpenWrt. The HomeHub got a bit old and can no longer cope with my internet speed so I bought the Linksys only to find that the disk does not work. I was looking forward to the fact that the Linksys has a USB 3.0 port. Imagine my disappointment.

Does anyone know if there is a fix for this?

Hi all,
I thought I would provide an update. I upgraded to OpenWrt 22.03.0-rc6 and installed all my default apps. I left the USB drive disconnected. Then after a while I plugged in the USB drive and it seemed to work fine. Obviously it wasn't mounted or anything so I installed:

kmod-usb-storage
kmod-usb-storage-uas 
usbutils 
block-mount
libblkid 
kmod-fs-exfat

Then, I mounted the drive and it worked.

I don't know if any of the above fixed the issue but I daren't reboot my router in case this is all coincidental. I hope this helps

Sooner or later you will have to reboot, and be it only a transient power outage due to lightning strike kilometers away. Better check it out now that your brain memory is still fresh, rather than in half a year, when you are unprepared.

1 Like

Another update. Looks like the method i described above is working. I upgraded to 22.03 GA and that obviously required a reboot and reinstallation of my packages. I kept the drive plugged in while I upgraded and reinstalled the apps including the USB drivers etc. and it's been fine.

Hi,

Thanks for sharing your experiences!

I have a question. Did you upgrade OpenWrt by flashing the sysupgrade.bin from within OpenWrt (and thereby erasing the Linksys firmware for good) or did you switch back to the Linksys firmware and then flashed the OpenWrt factory.bin from there?

I just upgraded a MR8300 to 22.03.0 and did the factory.bin. I would recommend anyone to do the same.

You have a fast and easy recovery if you need it.

@dr123 I upgraded from within OpenWrt. First to 22.03 RC6 then to the GA. I managed to get it to work when moving from 22.02 to 22.03 RC6 I plugged the drive in after upgrading then installed the drivers along with the other applications.

I will try the release version of 22.03 when I get a chance, but 22.03 RC6 definitely doesn't solve the USB problem for me.

So far I have always up- and downgraded OpenWrt by flashing the factory.bin from the Linksys firmware on the other partition.
Could that potentially make a difference?

By the way, is it actually possible to flash the sysupgrade.bin from the Linksys firmware when there is already an OpenWrt installed on the other partition?