Hello,
I have OpenWrt installed on R7800 with attached USB drive Seagate One Touch HDD.
Using the smartctl command shows error:
/dev/sda: Unknown USB bridge [0x0bc2:0xab63 (0x1707)]
Please specify device type with the -d option.
Same drive shows smartctl output on a dd-wrt router. How can i set it working on OpenWrt too?
Check the related package version in both firmwares.
Try the latest available OpenWrt release/snapshot build.
If the issue persists, try following the advice from the error message.
smartctl 7.2 2020-12-30 r5155 in both routers.
OpenWrt 22.03.5 r20134-5f15225c1e
I tried many options within drive type (smartctl -d) and nothing worked.
Any other ideas?
smartctl uses the file /var/lib/smartmontools/drivedb/drivedb.h to identify the drives. Compare this file on OpenWrt and dd-wrt. I assume these files are different, otherwise the output should be identical.
Hint: ssh to the router and type the following on the cmdline:
grep 0x0bc2 /var/lib/smartmontools/drivedb/drivedb.h
This will show all entries in the file, which have 0x0bc2 in their description.
My smartctl 7.2 2020-12-30 r5155 doesn't know anything about an USB device 0x0bc2:0xab63.
Looks like the database includes regexps:
This one should probably match:
Indeed.
@miro Please show your smartctl command line producing the above error message. Did you try the proposed -d option?
There is no such file on my router:
root@Home:/# cat /var/lib/smartmontools/drivedb/drivedb.h
cat: can't open '/var/lib/smartmontools/drivedb/drivedb.h': No such file or directory
root@Home:/# smartctl /dev/sda
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.176] (localbuild)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
/dev/sda: Unknown USB bridge [0x0bc2:0xab63 (0x1707)]
Please specify device type with the -d option.
Use smartctl -h to get a usage summary
root@Home:/# smartctl -d sat /dev/sda
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.176] (localbuild)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
ATA device successfully opened
Use 'smartctl -a' (or '-x') to print SMART (and more) information
root@Home:/# smartctl -d sat /dev/sda -a
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.176] (localbuild)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
Read Device Identity failed: scsi error unsupported field in scsi command
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
It should be present. smartctl needs this file for proper operation.
Did you install the package smartmontools-drivedb?
No. After installing it still have no such file:
root@Home:~# opkg list-installed | grep smartmon
smartmontools - 7.2-2
smartmontools-drivedb - 7.2-2
root@Home:~# cat /var/lib/smartmontools/drivedb/drivedb.h
cat: can't open '/var/lib/smartmontools/drivedb/drivedb.h': No such file or directory
opkg files smartmontools-drivedb
Check again, it should work now.
Sadly no.
root@Home:~# opkg files smartmontools-drivedb
Package smartmontools-drivedb (7.2-2) is installed on root and has the following files:
/usr/share/smartmontools/drivedb.h
root@Home:~# smartctl -x /dev/sda
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.176] (localbuild)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
Read Device Identity failed: scsi error unsupported field in scsi command
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
root@Home:~# smartctl -d sat -x /dev/sda
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.176] (localbuild)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
Read Device Identity failed: scsi error unsupported field in scsi command
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
Mea culpa, it's my fault. 
/var/lib/smartmontools/drivedb/drivedb.h is under a Debian installation, under an OpenWrt installation it's /usr/share/smartmontools/drivedb.h. Sorry for my mis-information.
Please compare the drivedb.h under OpenWrt with the file under dd-wrt. If they are different, this explains the different output. Otherwise the output should be identical.
There is no drivedb.h file on dd-wrt router.
I think you are digging in the wrong direction, Barney.
After installing smartmontools-drivedb on OpenWrt router i no longer receive the error
Unknown USB bridge [0x0bc2:0xab63 (0x1707)]
So drivedb must be fine in OpenWrt.
Now the error transformed into
Read Device Identity failed: scsi error unsupported field in scsi command
Reading the web it seems uas (USB Attached SCSI) kernel module is the problem.
How can i disable UAS in OpenWrt kernel?
This indicates a communication problem between smartmon and the hdd.
I would not blame the kernel module, but the hdd, which does not comply to the uas standards. Therefore I disabled uas on all my Linux based devices. That way all uas related problems vanished.
Just remove the package kmod-usb-storage-uas and reboot your router.
This caused missing /dev/sda after boot. I installed back kmod-usb-storage-uas
This should not happen. An uas hdd should operate with the kmod-usb-storage driver, if the uas driver is not available.
Please post the following information:
Do you have the chance to connect the hdd to a Linux-based PC? Do you see the same messages as with your router.
Last idea for today: uas drives are very picky about cabling, did you try another cable with the hdd?
This is the kernel log after boot with uninstalled uas:
When i seen the hdd is not recognized i installed back kmod uas and this appeared in kernel log:
[ 236.793982] kmodloader: loading kernel modules from /etc/modules.d/*
[ 236.802922] scsi host1: uas
[ 236.803621] usbcore: registered new interface driver uas
[ 236.804830] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 236.810379] scsi 1:0:0:0: Direct-Access Seagate One Touch HDD 1707 PQ: 0 ANSI: 6
[ 237.555445] sd 1:0:0:0: [sda] 7814037167 512-byte logical blocks: (4.00 TB/3.64 TiB)
[ 237.555496] sd 1:0:0:0: [sda] 4096-byte physical blocks
[ 237.562491] sd 1:0:0:0: [sda] Write Protect is off
[ 237.567322] sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
[ 237.572628] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 237.577999] sd 1:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[ 237.935916] sda: sda1 sda2 sda3
[ 237.942997] sd 1:0:0:0: [sda] Attached SCSI disk
[ 238.382693] Adding 999420k swap on /dev/sda1. Priority:-2 extents:1 across:999420k
root@Home:~# lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=, Driver=uas, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
root@Home:~# opkg list-installed | sort | grep ^kmod-usb
kmod-usb-core - 5.10.176-1
kmod-usb-dwc3 - 5.10.176-1
kmod-usb-dwc3-qcom - 5.10.176-1
kmod-usb-ehci - 5.10.176-1
kmod-usb-ledtrig-usbport - 5.10.176-1
kmod-usb-ohci - 5.10.176-1
kmod-usb-storage - 5.10.176-1
kmod-usb-storage-uas - 5.10.176-1
kmod-usb-xhci-hcd - 5.10.176-1
kmod-usb2 - 5.10.176-1
kmod-usb3 - 5.10.176-1
Did not tried different cable but same disk responds fine to smartctl when connected in dd-wrt router of same model R7800.
I think, your hdd is the problem, it does not identify itself as a mass storage device. I guess, that's the reason, why the usb-storage driver doesn't grep your hdd.
lsusb -t with my uas capable hdds looks this way (uas disabled):
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
May be.
What we know up to now is: smartctl is the same version in OpenWrt and dd-wrt.
As you said in a previous post: there is no drivedb.h file in dd-wrt. This file is essential for a proper smartctl operation, because it contains drive specific information.
Furthermore: what is dd-wrt's kernel version. Your installed OpenWrt uses kernel 5.10.x. Different kernel versions may result in different behaviour.