MT7601U with on-board storage reports incorrect capacity

MT7601U with on-board storage reports incorrect capacity

[Bitterblue Smith]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

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?

usb_modeswitch can switch it to wifi mode, so it's not a huge problem.
I'm just curious.

[-- Attachment #2: mt7601u-linux.pcapng --]
[-- Type: application/x-pcapng, Size: 67624 bytes --]

[-- Attachment #3: mt7601u-windows.pcapng --]
[-- Type: application/x-pcapng, Size: 155392 bytes --]

Re: MT7601U with on-board storage reports incorrect capacity

[Alan Stern]

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

Re: MT7601U with on-board storage reports incorrect capacity

[Bitterblue Smith]

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.

Re: MT7601U with on-board storage reports incorrect capacity

[Alan Stern]

On Thu, Jan 09, 2025 at 08:57:29PM +0200, Bitterblue Smith wrote:
> 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:

> >> How can this be fixed?

> > 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.

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

Not hopeless at	all.  The module parameter approach really should work,	
at least to the	extent of getting rid of those annoying	17-second-long 
waits.

Alan Stern

Re: MT7601U with on-board storage reports incorrect capacity

[Bitterblue Smith]

On 09/01/2025 21:38, Alan Stern wrote:
> On Thu, Jan 09, 2025 at 08:57:29PM +0200, Bitterblue Smith wrote:
>> 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:
> 
>>>> How can this be fixed?
> 
>>> 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.
> 
>> Haha, so it's hopeless. Thank you for the detailed explanation.
> 
> Not hopeless at	all.  The module parameter approach really should work,	
> at least to the	extent of getting rid of those annoying	17-second-long 
> waits.
> 
> Alan Stern

But it's fine. usb_modeswitch switches it right away.