[snip]
> write(2, "[canon] attach: sending GET SCAN"..., 66[canon] attach: sending GET SCAN MODE for scan control conditions
> ) = 66
> write(2, "[canon] get scan mode: cmd[4]=\'0"..., 37[canon] get scan mode: cmd[4]='0x14'
> ) = 37
> rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
> write(4, "*\0\0\0n\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 42) = -1 EIO (Input/output error)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Laura,
Thanks for that information.
The failure (EIO) on the sg device handle (4 in this case)
indicates the buffer passed to sg's write() was too small.
A length of 42 implies a maximum SCSI command length of 6
bytes (because the accompanying sg_header structure is 36
bytes long). Digging around the canon backend code in
sane-1.0.1, it seems to be sending an opcode of 0xd5
for "GET SCAN MODE". Such an opcode can only be 10 bytes
long (12 bytes if another flag was set but I can see above
it is not).
If you don't understand what I'm talking about, that's
fine. Hopefully the maintainer of the Canon backend does.
Mine is a "down under" view of what is going on here
so maybe someone with a different perspective could
shed some light on this.
Still can't answer why it locks your machine as root.
Doug Gilbert
Linux sg maintainer
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com