Re: MT7601U with on-board storage reports incorrect capacity

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 09/01/2025 17:34, Alan Stern wrote:
> On Thu, Jan 09, 2025 at 04:02:58PM +0200, Bitterblue Smith wrote:
>> Hi,
>>
>> I have this wifi device with on-board storage for the Windows driver:
>>
>> New USB device found, idVendor=148f, idProduct=2878, bcdDevice= 0.01
>>
>> After switching to wifi mode, we can see it's a MT7601U:
>>
>> New USB device found, idVendor=148f, idProduct=7601, bcdDevice= 0.00
>>
>> The problem with this one is that it can't be mounted, nothing happens
>> for a long time. I'm testing with kernel 6.12.8-arch1-1 but it's been
>> like this for at least two years. 
>>
>> The problem seems to be that reading from the "end" of the device
>> takes 17 seconds. I assume the reason for that is the fake capacity:
>>
>> SCSI Payload (Read Capacity(10) Response Data)
>>     [LUN: 0x0000]
>>     [Command Set:CD-ROM (0x05) ]
>>     [MMC Opcode: Read Capacity(10) (0x25)]
>>     [Request in: 212]
>>     [Response in: 217]
>>     LBA: 65280 
>>     Block size in bytes: 2048
>>     Read capacity: 133693440 bytes (127.50 MiB)
>>
>> The real capacity is probably just 8 MiB. The driver files stored in
>> it are ~7 MiB total.
>>
>> This takes 17 seconds and returns 4096 bytes filled with 0xff:
>>
>> SCSI CDB Read(10)
>>     [LUN: 0x0000]
>>     [Command Set:CD-ROM (0x05) ]
>>     [Response in: 565]
>>     Opcode: Read(10) (0x28)
>>     Flags: 0x00
>>     Logical Block Address (LBA): 0x0000fefc (65276)
>>     ...0 0000 = Group: 0x00
>>     Transfer Length: 2
>>     Control: 0x00
>>
>> Windows never tries to read that far. (The device works in Windows.)
>>
>> How can this be fixed?
> 
> Upgrade the WiFi device's firmware.  If you can convince the vendor to 
> fix the bug, which seems unlikely because it works okay with Windows.
> 
> Part of the partition probing (which tries to read the device's last 
> sector) is done by various userspace programs.  But I think some of it 
> is also done by the kernel, and as far as I know the only way to prevent 
> it is to build a kernel without support for the partition schemes which 
> store some of their data near the end of the device.
> 
> Probably your best approach is to tell usb-storage to ignore the device 
> completely.  You can do this with a suitable module parameter for the 
> usb-storage driver.  For example, add:
> 
> 	usb-storage.quirks=148f:7601:i
> 
> on the kernel's boot command line (or put a similar entry in an 
> /etc/modprobe.d/*.conf file if usb-storage is a loadable kernel module 
> on your system).  Of course, then you wouldn't be able to mount the 
> device or access the Windows driver files on it, but I imagine you don't 
> care about them very much while you're running Linux.
> 
>> usb_modeswitch can switch it to wifi mode, so it's not a huge problem.
>> I'm just curious.
> 
> If you really wanted, you could create a custom kernel which which 
> adjust the storage capacity of this particular device down to 8 MB.  But 
> you would never be able to convince anyone to include such a workaround 
> in the main kernel.
> 
> Alan Stern

Haha, so it's hopeless. Thank you for the detailed explanation.