[EMAIL PROTECTED] wrote:
The SCSI code has no means of knowing the actual length transferred, so has no choice but to believe the length byte in the reply. But the USB code does the transferring itself, and knows precisely how many bytes were transferred. If 36 bytes were transferred and the additional length byte is 0, indicating a length of 5, then the USB code can fix the response and change the additional length byte to 31, indicating a length of 36. That way the SCSI code knows that not 5 but 36 bytes are valid, and it gets actual vendor and model strings.
And what if the transport is *not* USB? Or they used a similar firmware of their device server in another product which used another transport? I suggest that this device is blacklisted in that SCSI Core would know that the ADDITIONAL LENGTH field in the INQURY response is incorrectly set (to 0). I.e. leave it to the interpreter. A transport is *not* supposed to peek and poke in the data it transfers! -- Luben ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
