USB storage detachment / reattachment

[Boris Mulder]

all right, now I'm using a sandisk usb (<device vendor_id="0x0781"
product_id="0x5591"/>), and it does not give this error. However, when I
try to list the files and their contents in the root directory using
File_system::read, it gives a bunch of other errors:

[init -> media] child "rump_fs1" announces service "File_system"

(here it calls dir() )

[init -> media -> usb_blk] Error: complete error: packet not succeded
[init -> media -> usb_blk] Error: request pending: tag: 5 read: 0
buffer: 0x406800 lba: 7423 size: 4096

(here it calls File_system::read() )

[init -> media -> usb_blk] Error: complete error: packet not succeded
[init -> media -> usb_blk] Error: request pending: tag: 6 read: 1
buffer: 0x406800 lba: 11511 size: 4096
[init -> media -> usb_blk] Error: complete error: packet not succeded
[init -> media -> usb_blk] Error: request pending: tag: 7 read: 1
buffer: 0x406800 lba: 11511 size: 4096

and from here these errors keep coming infinitely (with the same error
code, except for the tag which is advancing). It looks like it retries
to get some packet all the time without stopping.

apparently, it does see the dir_handle returned by dir("/") as valid
(the valid() check succeeds).

Any ideas as to which causes this?


On 10-02-17 18:23, Josef Söntgen wrote:
> Hello Boris,
>
> * Boris Mulder <boris.mulder at ...434...> [2017-02-10 14:12:18 +0100]:
>> Now, I'm spawning this usb block driver dynamically, which then tries to
>> connect to the usb driver. In my scenario, the usb driver is found, but
>> at some point the usb_block just hangs at the first time it reaches the
>> line:
>>
>> iface.bulk_transfer(p, ep, block, &c);
>>
>> (usb_block/main.cc line 308, called from line 432 as I verified with
>> print statements in the code)
>>
>> the bulk_transfer method (with block=true) blocks indefinitely.
> It looks like the INQUIRY command does not complete; I already observed
> this behaviour with a Delock USB SATA adapter. When using a HDD, we
> might need to issue a START STOP UNIT command to get the device into
> working state before executing any other command but I did not look
> into that so far.
>
>> <config uhci="yes" ehci="yes" xhci="yes">
>>     <hid/>
>>     <raw>
>>     <report devices="yes"/>
>>     <policy label="media -> usb_blk -> usb-1-3" vendor_id="0x058f" product_id="0x6387" bus="0x0001" dev="0x0003"/>
>>     </raw>
>> </config>
> That being said, judging by the vendor and product id, you are using a
> Transcend USB stick. We had problems with such sticks in past, even
> when using the usb_drv's in-build storage driver. So could you please
> try using another vendor, just to make sure, that it is indeed the
> combination of stick and driver that does not work.
>
> It is mostly likely that we might not wait long enough in the usb_block
> driver for the device to get itself into a working state or that we
> do not do all of the configuration necessary, i.e., appyling quirks
> and stuff, to get it there.
>
>
> Regards
> Josef
>

-- 

Met vriendelijke groet / kind regards,

Boris Mulder

Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office)