[sane-devel] Problem with Olivetti Job_Jet M400
Henning, Thanks a lot, here are the results of sane-find-scanner -v -v device descriptor of 0x0b3c/0xa880 at 003:003 (Olivetti Job_Jet M400) bLength 18 bDescriptorType 1 bcdUSB2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0B3C idProduct 0xA880 bcdDevice 1.00 iManufacturer 1 (Olivetti) iProduct 2 (Job_Jet M400) iSerialNumber 3 (MY43FT62DF82) bNumConfigurations1 configuration 0 bLength 9 bDescriptorType 2 wTotalLength 99 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 () bmAttributes 192 (Self-powered) MaxPower 2 mA interface 0 altsetting 0 bLength9 bDescriptorType4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass255 bInterfaceSubClass 204 bInterfaceProtocol 0 iInterface 0 () endpoint 0 bLength 7 bDescriptorType 5 bEndpointAddress 0x01 (out 0x01) bmAttributes 2 (bulk) wMaxPacketSize64 bInterval 0 ms bRefresh 0 bSynchAddress 0 endpoint 1 bLength 7 bDescriptorType 5 bEndpointAddress 0x81 (in 0x01) bmAttributes 2 (bulk) wMaxPacketSize64 bInterval 0 ms bRefresh 0 bSynchAddress 0 endpoint 2 bLength 7 bDescriptorType 5 bEndpointAddress 0x82 (in 0x02) bmAttributes 3 (interrupt) wMaxPacketSize8 bInterval 10 ms bRefresh 0 bSynchAddress 0 interface 1 altsetting 0 bLength9 bDescriptorType4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass7 bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 () endpoint 0 bLength 7 bDescriptorType 5 bEndpointAddress 0x03 (out 0x03) bmAttributes 2 (bulk) wMaxPacketSize64 bInterval 0 ms bRefresh 0 bSynchAddress 0 endpoint 1 bLength 7 bDescriptorType 5 bEndpointAddress 0x83 (in 0x03) bmAttributes 2 (bulk) wMaxPacketSize64 bInterval 0 ms bRefresh 0 bSynchAddress 0 endpoint 2 bLength 7 bDescriptorType 5 bEndpointAddress 0x84 (in 0x04) bmAttributes 3 (interrupt) wMaxPacketSize8 bInterval 10 ms bRefresh 0 bSynchAddress 0 interface 2 altsetting 0 bLength9 bDescriptorType4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass255 bInterfaceSubClass 255 bInterfaceProtocol 255 iInterface 0 () endpoint 0 bLength 7 bDescriptorType 5 bEndpointAddress 0x05 (out 0x05) bmAttributes 2 (bulk) wMaxPacketSize64 bInterval 0 ms bRefresh 0 bSynchAddress 0 endpoint 1 bLength 7 bDescriptorType 5 bEndpointAddress 0x85 (in 0x05) bmAttributes 2 (bulk) wMaxPacketSize64 bInterval 0 ms bRefresh 0 bSynchAddress 0 endpoint 2 bLength 7 bDescriptorType 5 bEndpointAddress 0x86 (in 0x06) bmAttributes 3 (interrupt) bRefresh 0 trying to find out which USB chip is used checking for GT-6801 ... this is not a GT-6801 (bDeviceClass = 0) checking for GT-6816 ... this is not a GT-6816 (bcdUSB = 0x200) checking for MA-1017 ... this is not a MA-1017 (bDeviceClass = 0, bInterfaceClass = 255) checking for MA-1015 ... this is not a MA-1015 (bDeviceClass = 0) checking for MA-1509 ... this is not a MA-1509 (bDeviceClass = 0) checking for LM983[1,2,3] ... this is not a LM983x (bcdUSB = 0x200) checking for GL646 ... this is not a GL646 (bDeviceClass = 0, bInterfaceClass = 255) checking for GL660+GL646 ... this is not a GL660+GL646 (bDeviceClass = 0, bInterfaceClass = 255) Couldn't determine the type of the USB chip found USB scanner (vendor=0x0b3c [Olivetti], product=0xa880 [Job_Jet M400]) at libusb:003:003 Regards Livhu
[sane-devel] Timetable for the release of sane-backends-1.0.15
Am Fre, 2004-10-15 um 16.44 schrieb Oliver Rauch: Hello. I am not able to get access to the CVS server (permission denied). Please could someone who has acces to the server take a look at that?! I suggest to delay the feature freeze for some days when this is not solved soon. Today everything works right again, no need for a delay. Oliver
[sane-devel] Timetable for the release of sane-backends-1.0.15
Oliver Rauch oliver.ra...@rauch-domain.de wrote: I am not able to get access to the CVS server (permission denied). Please could someone who has acces to the server take a look at that?! It should be working again, LDAP crashed again. JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169
[sane-devel] Snapscan: Epson 2480 hangs on amd64
Hi, My Epson 2480 hangs when doing a preview on an amd64 box, however it works fine on both an i386 and a PowerPC boxes. Here's the end of the log : [snapscan] sane_snapscan_start: after measuring speed: 3816 bytes per scan line 0.00 milliseconds per scan line. ==inf bytes per millisecond [snapscan] calibrate: reading calibration data (1 lines) [snapscan] read_calibration_data [snapscan] snapscan_cmd [snapscan] snapscani_usb_cmd(0,0x647088,10,0x75fdb0,0xbfffe438 (61200)) [snapscan] atomic_usb_cmd(0,0x647088,10,0x75fdb0,0xbfffe438 (61200)) [snapscan] usb_cmd(0,0x647088,10,0x75fdb0,0xbfffe438 (61200)) [snapscan] usb_cmd: cmdlen=10, datalen=0 [snapscan] usb_write: writing: 0x28 0x00 0x82 0x00 0x00 0x01 0x00 0xef 0x10 0x00 [snapscan] Written 10 bytes [snapscan] usb_read: reading: 0xf9 0x00 0x00 0x00 0x00 0x00 0x00 0x00 [snapscan] Read 8 bytes [snapscan] usb_read Only 0 bytes read [snapscan] usb_read: reading: 0x5e 0x5d 0x63 0x60 0x60 0x5d 0x62 0x5e 0x60 0x64 ... [snapscan] Read 0 bytes [snapscan] read_calibration_data: snapscan_cmd command failed: Error during device I/O [snapscan] calibrate: read_calibration_data command failed: Error during device I/O [snapscan] sane_snapscan_start: calibration failed. [snapscan] release_unit [snapscan] snapscan_cmd [snapscan] snapscani_usb_cmd(0,0xbfffe480,6,0x0,0x0 (0)) [snapscan] atomic_usb_cmd(0,0xbfffe480,6,0x0,0x0 (0)) [snapscan] usb_cmd(0,0xbfffe480,6,0x0,0x0 (0)) [snapscan] usb_cmd: cmdlen=6, datalen=0 [snapscan] usb_write: writing: 0x17 0x00 0x00 0x00 0x00 0x00 [snapscan] usb_write Only 0 bytes written [snapscan] Written 0 bytes [snapscan] release_unit: scsi command error: Error during device I/O [snapscan] sane_snapscan_cancel [snapscan] release_unit [snapscan] snapscan_cmd [snapscan] snapscani_usb_cmd(0,0xbfffe3b0,6,0x0,0x0 (0)) [snapscan] atomic_usb_cmd(0,0xbfffe3b0,6,0x0,0x0 (0)) [snapscan] usb_cmd(0,0xbfffe3b0,6,0x0,0x0 (0)) [snapscan] usb_cmd: cmdlen=6, datalen=0 [snapscan] usb_write: writing: 0x17 0x00 0x00 0x00 0x00 0x00 [snapscan] usb_write Only 0 bytes written [snapscan] Written 0 bytes [snapscan] release_unit: scsi command error: Error during device I/O [snapscan] close_scanner [snapscan] snapscani_usb_close(0) [snapscan] 1st read 977 write 411 [snapscan] usb_cmd(0,0xbfffe3b0,6,0x0,0x0 (0)) [snapscan] usb_cmd: cmdlen=6, datalen=0 [snapscan] usb_write: writing: 0x00 0x00 0x00 0x00 0x00 0x00 [snapscan] usb_write Only 0 bytes written [snapscan] Written 0 bytes [snapscan] 2nd read 977 write 411 dmesg indicates the usb operations time out (ret -110). JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169
[sane-devel] Timetable for the release of sane-backends-1.0.15
Hi, On Fri, Oct 15, 2004 at 04:44:42PM +0200, Oliver Rauch wrote: I am not able to get access to the CVS server (permission denied). Please could someone who has acces to the server take a look at that?! The reason was a 100% full / file system which stopped login and other services like mail. As far as I can see it's fixed now. As the mailinglists are hosted on the same server as CVS (alioth.debian.org), they usually don't work when CVS is broken by such failures. The IRC channel #sane is not affected as it's independent from alioth. So better ask there when CVS or anything else is broken. Bye, Henning
[sane-devel] Problem with Olivetti Job_Jet M400
Hi, On Sat, Oct 16, 2004 at 08:04:34AM +0200, Livhu Tshisikule wrote: Henning, Thanks a lot, here are the results of sane-find-scanner -v -v Thanks. I'll add that scanner as unsupported to our lists. Bye, Henning
[sane-devel] possible bin_w_string security issue (not)
Hi,
On Fri, Oct 15, 2004 at 03:47:06PM +0200, Johannes Berg wrote:
I was going to write a mail without the (not) but then discovered that
this issue is actually a non-issue, but this is totally non-obvious.
Would you know off-hand why?
SIGPIPE (ok, I read your mail before answering) :-)
bin_w_string contains the following code:
if (w-direction == WIRE_DECODE)
{
if (len == 0)
*s = 0;
else if (w-status == 0)
*(*s + len - 1) = '\0';
}
If I interpret the code correctly, this could be used to bring the
server (running the binary protocol) into an invalid state:
Nearly any protocol violation from server or client can have strange
results. That's one of the problems with the SANE net protocol.
Also there are still many tests missing for a bad wire status (see bug
#300105).
* now, the server has a password string that is not zero terminated,
and strcpy()s that string accessing memory beyond the allocated size.
There may be other locations but at least here it tests for the wire
status:
(saned.c l. 356)
sanei_w_authorization_req (wire, req);
if (wire.status)
{
DBG(DBG_ERR, auth_callback: bad status %d\n, wire.status);
return;
}
if (req.username)
strcpy (username, req.username);
[...]
All the wire code expects the caller to test the wire status before he
does anything else. I think there should be tests in all functions of
sanei_net.c also to avoid calling sanei_wire again when the wire is
already bad.
[Actually, I discovered this while I was documenting the wire protocol.
I think it is overly complex and the code badly structured, the wire's
direction thing is really strange!]
I'm still not sure if I have understood all the details of the wire
code. But I guess the idea was to have only one function for each kind
of data. So you don't need one for the server and one for the client
and one for ascii and one for bin and one for sending and one for
receiving...
Ok, so here's the solution:
The server does
signal (SIGPIPE, quit);
(which I think is actually another bug, why should sane_close,
sane_exit, sanei_w_exit and lots of other functions be async signal
safe?)
They aren't. Only sane_cancel() must be async signal safe.
Yes, I guess that's a bug.
Still, this is that non-obvious that someone writing a server (or
client, which could then be attacked by a malevolent server) with the
sanei library functions could easily oversee this detail, ignore SIGPIPE
or use sockets that don't raise it.
Nobody should ever use sanei_wire/sanei_net/sanei_codec_* without
really knowing what he does :-)
Therefore I'm still sending this mail in hope that someone fixes the
sanei_w_array function to check for status != 0 and clean up after
itself.
But what should sanei_w_array do? It already exits when the wire is in
bad state. I think that's really up to the caller.
Bye,
Henning
[sane-devel] Snapscan: Epson 2480 hangs on amd64
Hi, [snapscan] read_calibration_data: snapscan_cmd command failed: Error during device I/O [snapscan] calibrate: read_calibration_data command failed: Error during device I/O [snapscan] sane_snapscan_start: calibration failed. the error occurs during quality calibration. It's a known issue that quality calibration as implemented in the snapscan backend doesn't work for epson scanners. For that reason the option is disabled for epson models (see snapscan-options.c, line 522ff). In this case the calibrate function should never be called (see snapscan.c, line 1600). Either you're using a wrong version of the backend or there's some issue with option handling on amd64. /Oliver
[sane-devel] possible bin_w_string security issue (not)
--=-yhkGcHckmX4ZO5PEvTHQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, SIGPIPE (ok, I read your mail before answering) :-) :-) Nearly any protocol violation from server or client can have strange results. That's one of the problems with the SANE net protocol. =20 Also there are still many tests missing for a bad wire status (see bug #300105). Will do. There may be other locations but at least here it tests for the wire status: Hm. I guess you're right. Seems I missed it, or maybe I was writing this when I looked at a different location? Sorry. I'm still not sure if I have understood all the details of the wire code. But I guess the idea was to have only one function for each kind of data. So you don't need one for the server and one for the client and one for ascii and one for bin and one for sending and one for receiving... Yeah, and then it is also overloaded for freeing allocated data. They aren't. Only sane_cancel() must be async signal safe. =20 Yes, I guess that's a bug. Ok. Nobody should ever use sanei_wire/sanei_net/sanei_codec_* without really knowing what he does :-) :-) But what should sanei_w_array do? It already exits when the wire is in bad state. I think that's really up to the caller. Yes, but before exiting it should free the result buffer and NULL the pointer. When the wire is in an invalid state during reading, it cannot be guaranteed that the buffer is in a valid state, so should be discarded. johannes --=-yhkGcHckmX4ZO5PEvTHQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Comment: Johannes Berg (SIP Solutions) iQIVAwUAQXEVXaVg1VMiehFYAQLPOw/9E6+OseXpkvwWNMTenxSGxMF28XX/Rl71 s7sYiR4Fg9hdmPQDy0RtTkQrKspY6izzgn1aGlsH7H2eLw2pIF7yqW36vX2gQXWo kwju+ZF+dIDLWjQ8ICiyuJFgYUNWxjZjDTfLhwe16ByGnVT+nWIx9ZbPYaB1KR0N PmqH3M9G+s7oaZFh5zKtPiJA6kSBbsgpnhSDZpqzop+Rfe8vrFIPN7UTQS2PqZUx 20kMuH4CQu0ggpJ9yekIfzRdbBAZcHSCxKo7vTuupfratbbib9D2firVgW77aaNO Lo3gnue+/TgxLJWeaBxrn/unL/q5U/YnNGhUgAsDBlGymjpZJV+ApOYHoVarv5XS CbyYKKrszzhO8otxfkfA07v7QxqqpDw1CRE2tfxHqXyk2hmyVsy38AHrZOyevMGS D2du8D63miUyVaU3dlGrjmcSxE7pohki9BpMjZ54hIEiF0zw2H9pC1/363KWNzl+ 2rVZcrCmBQMrwoewepWGpvQBJiFZ9sxUkAmaQu/Jv3HEOQnsX8ZmQwKZpKy1qPHm ARqx2Yex/OJ8R8ViKQfPjpRVyBvYfchle+XNRpJh+lbn2VGwh4KKWNGaaoFqdOJd Ybwv5LTz7XtYFmR3IOssFp8BjrTULE5oezwrwCFLqyIJAGC64dGnkdTli6xlEp2E h41UsBd5daQ= =cJpn -END PGP SIGNATURE- --=-yhkGcHckmX4ZO5PEvTHQ--
[sane-devel] Snapscan: Epson 2480 hangs on amd64
Oliver Schwartz oliver.schwa...@gmx.de wrote: Hi Oliver, [snapscan] read_calibration_data: snapscan_cmd command failed: Error during device I/O [snapscan] calibrate: read_calibration_data command failed: Error during device I/O [snapscan] sane_snapscan_start: calibration failed. the error occurs during quality calibration. It's a known issue that quality calibration as implemented in the snapscan backend doesn't work for epson scanners. For that reason the option is disabled for epson models (see snapscan-options.c, line 522ff). In this case the calibrate function should never be called (see snapscan.c, line 1600). This is fresh checkout, and the code seems OK. There is something fishy going on... now it doesn't even find the scanner anymore. I'll dig into it. Either you're using a wrong version of the backend or there's some issue with option handling on amd64. Looks like it :/ JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169
[sane-devel] weird message configuring sane-frontends
Hi, On Fri, Oct 15, 2004 at 04:03:24PM +0200, Johannes Berg wrote: [configure fails because it can't find sane-config] You may need to remove /dev/null before you run configure again. Clearly, that is not something you want to do. That's the penalty for users who don't read the docs and install sane-frontends before sane-backends :-) Fixed in CVS now. The idea was to print the name of the cache filr of autoconf (usually ./config.cache). Recent autoconf versions don't use it and set the variable to /dev/null. Bye, Henning
[sane-devel] saned/sanei net bug
Hi, On Fri, Oct 15, 2004 at 04:03:04PM +0200, Johannes Berg wrote: somehow saned/the sanei network layer seem to get buffering wrong. I'm afraid that that's intentional. But that's only a guess. For example, I send the following: SANE_NET_INIT SANE_NET_GET_DEVICES SANE_NET_EXIT If I don't wait for the result from SANE_NET_GET_DEVICES before sending the control code for SANE_NET_EXIT, then the SANE_NET_EXIT code is discarded. I think you must really read the result of any RPC before sending the next one. I would assume that somewhere there's a buffering problem and the old buffer is simply dropped when the direction is changed or something. That's done in sanei_w_set_direction(). Set SANE_DEBUG_SANEI_WIRE=255 and you'll even get a warning :-) The following works: (echo -n -e \\00\\00\\00\\00\\00\\00\\00\\00\\00\\00\\00\\00 ; sleep .1 ; echo -n -e \\00\\00\\x00\\x01 ; sleep 1 ; echo -en \\x00\\x00\\x00\\x0A ) | nc localhost 6566 -q 1 | hd while this doesn't: (echo -n -e \\00\\00\\00\\00\\00\\00\\00\\00\\00\\00\\00\\00 ; sleep .1 ; echo -n -e \\00\\00\\x00\\x01\\x00\\x00\\x00\\x0A )| nc localhost 6566 -q 1 | hd I think this is extremely counter-intuitive. TCP never guarantees message boundaries, so one wouldn't think that data is explicitly read by the application but then discarded. I guess you are right but I don't really know how to fix that with the current code. One option would be to set the wire to error state (and exit?) when data is discarded. Bye, Henning
[sane-devel] [BUG] saned: missing input sanitization
Hi, On Fri, Oct 15, 2004 at 03:47:40PM +0200, Johannes Berg wrote: SANE_NET_OPEN makes saned segfault if a NULL name is passed, because it tries to strdup() the name without checking for != NULL. I've added a check to CVS. It returns an error to the client because I think that's a protocol violation. Zero-length strings are allowed for sane_open but not NULL-pointers. Could you check if that works and doesn't create any new bugs? Bye, Henning
[sane-devel] [BUG] saned: missing input sanitization
--=-RvFmJl5eUaAjiXBPw3Ib Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2004-10-16 at 15:48 +0200, Henning Meier-Geinitz wrote: I've added a check to CVS. It returns an error to the client because I think that's a protocol violation. Zero-length strings are allowed for sane_open but not NULL-pointers. I think the problem is that the network layer does not distinguish between zero-length strings and NULL pointers -- as far as I can see it interprets a zero-length string (which is only a byte-array after all) as a NULL string. johannes --=-RvFmJl5eUaAjiXBPw3Ib Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Comment: Johannes Berg (SIP Solutions) iQIVAwUAQXEpq6Vg1VMiehFYAQKfdw/8DmtQmW6bABrsnmshQFN+syVsTAZWFhRO 0veLBoM8uNxgFMLXUtiXhv0lWfbZdce6UXYREB3bPy2yrAIsm30rFipBGvckX9J9 RvmH21mrigWiYn5VoloGIqiCDum/BubxyeE/xSBkcVcDKh3wnOWtYzFDBEnyP79U rUz0bMlchKHcKrPsZq78WeJ203hZaPBxPgmRKT/i/kjdOFMIiu/enMC8VEFrl3Oe AhbXOhtj5GtkfPs1ueM5oms4f4wu4La+lF6+5lhHGFOY6Bwj+Xd0xwvxPge36NXD NRn7XArGv9SLUPza1y9Nw6wlVMFpG4AdlUyTTH3zO28A8bOjksSC53p/ftl/x9z1 wE4j1yBvzUmlrCYmSYvPgzXG5Kwv6CndtE3+v6+f2dYrY80yMCLLWyMG1XLgKtvT oDtuUFdpzOPSQSDWz7ICkCyl1Vv+5DiWlchXBqN5cHz/1mDMZOj9VAmtoo+b28kA tIeEFq3q0ITTwJps6nrmUDshGDAiVWj86NH7y+Q6py0EmG8eHav1MvDdxiz5r7/x Q160C87JrAfMgxl5o84zGF63XJHH4k6e0RLNEqDLCg6u0K+qZ9tkUgNQOLZ5Ym9Q LcqYgokfISbLEfit7V4fp9lXz75ZU7HYsaDnsOKKH/EI0v3F1xzHQUG2LMNywlBj 8XQQi/XDORw= =iuNs -END PGP SIGNATURE- --=-RvFmJl5eUaAjiXBPw3Ib--
[sane-devel] [BUG] saned: missing input sanitization
Hi, On Sat, Oct 16, 2004 at 04:01:20PM +0200, Johannes Berg wrote: I think the problem is that the network layer does not distinguish between zero-length strings and NULL pointers -- as far as I can see it interprets a zero-length string A zero length string is e.g. SANE_String hubba = ; (which is only a byte-array after all) For sane_net a zero-lenth string is 0 0 0 1 0 (Array of length 1 which only contains a 0 byte as end marker). as a NULL string. I hope it doesn't. A NULL string is encoded as an array of length 0 (and has no data). zero-length is ok in sane_open, NULL isn't. Bye, Henning
[sane-devel] [BUG] saned: missing input sanitization
--=-5n0e72bCo6NIQyEFjdhX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2004-10-16 at 16:10 +0200, Henning Meier-Geinitz wrote: For sane_net a zero-lenth string is 0 0 0 1 0 (Array of length 1 which only contains a 0 byte as end marker). Reading through the code again -- looks like you're right. Somehow I got the impression that it was the same, but don't remember where I read that now. johannes --=-5n0e72bCo6NIQyEFjdhX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Comment: Johannes Berg (SIP Solutions) iQIVAwUAQXEuxqVg1VMiehFYAQKFVw//Uyr9ZkUO2zjzW/eDiaqWKp6o14qOwMDF 3p7QClunjZDGLPz3Bzt7mDZtqaecyy0Dly1Be0nk5LDOphvnuRk+OucWmrCcDfQT dTmqnfScp0G+bzKEawnrBNC4nPiimJnqEEpdLcPv/tx1wi2AZ8yQZBx7lW5anjc0 Ewl3Ssnx3dVxu+MsfqXVwN+I+cTFVai7uDANnkqNl9UGi9MxUb0w34ZsGSkqdtJf 8VyTOzvrpq3cfe1yD2NL5uHAsb4fJ6+3KcfOzo/vXxJgKHFwI4R6DodwyOTjZnCT 4+MTcQEJCEEsYXPGwYCBqv33NTN1/y7VGFfAoHQycQu9VAfjo0uec5Gffzrc3szd 2lnaTAt94hRLtd1QxdgjQMMj3QBIPHz6FRvet+IQb7t97A4I294/32oQV4S425R/ brkA4BOEEzyHihFard7V2o3404frglJZGWUOBKqYRYcypmzyIk73xLFnyvHQnaAm qG9uUxzDvtamzYmcst0v25MsGDzqyGVOfryLaWV6uMMmms3MWU9y7Y20MQMvBrjT Yl6w/t85C/nomxiVftTS+8H6hKbVExB57TMN9SnQUN4tjw1LD1TCwROkl6BExpHI D3GDSfWojZ2emFoZsIbJ+PKoq79K/MWFyE5DDpk4Qv/sPd6h9oII3qgBTSWZHR5H MIOXVanpyXU= =Ilg2 -END PGP SIGNATURE- --=-5n0e72bCo6NIQyEFjdhX--
[sane-devel] Problems with libusb (WAS:Upgrading sane-backend on Mandrake 10.0)
Henning Meier-Geinitz wrote: Hi, On Fri, Nov 22, 2002 at 08:03:23AM -0800, Lloyd Sumpter wrote: Strange date. Sorry, had just rebooted (from the problems between harddrake and sane-find-scanner) and hadn't run rdate yet. snip BTW: The reason I have to upgrade is that apparently the sane-backends included with Mandrake 10.0 do NOT support libusb (but since the kernel is 2.6.x, there's no scanner.o to use instead...) sane-backends supports libusb since quite some time. And it was needed before kernel 2.6 at least for some scanners. So I'd be surprised if the Mandrake version had no libusb support. You can check by running sane-find-scanner -v -v. It should print messages about using libusb. Thanks for your help! But on Sept 29, you wrote: On Tue, Sep 28, 2004 at 01:22:01PM -0700, Lloyd Sumpter wrote: [sanei_debug] Setting debug level of sanei_usb to 255. [sanei_usb] sanei_usb_init: couldn't open /dev/usb/scanner0: No such device [sanei_usb] sanei_usb_init: found 0 devices Oh. That means that SANE isn't built with libusb support. It only searches for /dev/usb/ but not for libusb devices. As your sane-find-scanner program finds libusb devices, maybe you have an old installation of the SANE backends without libusb support that's used by scanimage? Note that sane-find-scanner DOES find the scanner (using libusb), but scanimage does not. PLEASE, any help would be appreciated - I've been working on this for weeks! Lloyd Sumpter
[sane-devel] Problems with libusb (WAS:Upgrading sane-backend on Mandrake 10.0)
Hi, On Sat, Oct 16, 2004 at 08:35:28AM -0700, Lloyd Sumpter wrote: You can check by running sane-find-scanner -v -v. It should print messages about using libusb. Thanks for your help! But on Sept 29, you wrote: Oh, different thread, same problem? I usually don't look at the author's name :-) Oh. That means that SANE isn't built with libusb support. It only searches for /dev/usb/ but not for libusb devices. As your sane-find-scanner program finds libusb devices, maybe you have an old installation of the SANE backends without libusb support that's used by scanimage? Note that sane-find-scanner DOES find the scanner (using libusb), but scanimage does not. Ok. PLEASE, any help would be appreciated - I've been working on this for weeks! See above. Have you checked if you don't use two different installations of SANE? E.g. check sane-find-scanner: ldd /usr/bin/sane-find-scanner Check libsane: ldd /usr/lib/libsane.so.1 And to be safe, check the plustek backend: ldd /usr/lib/sane/libsane-plustek.so.1 Also check if scanimage is linked to the right sane-backend libs: ldd /usr/bin/scanimage You may need to adjust the paths. All should print something about libusb. If sane-find-scanner is linked to libusb and libsane isn't, better ask your distributer what the heck they are doing. Bye, Henning
