Okay, I configured the SANE DLL backend for both my Microtek X6 EL scanner
and for net access. Net access is configured to consult localhost for
scanners. I have saned being run by inetd vs. as a standalone daemon. If I
run:
$ scanimage -L
I get:
device `microtek2:/dev/sga' is a Microtek ScanMaker X6EL flatbed scanner
It doesn't list the scanner through the network. I wrote a little wrapper
script to initialize the environment for saned that's invoked through inetd
in lieu of saned:
#!/bin/sh
SANE_DIR=/usr/local/SANE
SANE_DEBUG_LOG=$SANE_DIR/var/log/saned.log
SANE_DEBUG_DLL=128
SANE_DEBUG_NET=128
SANE_DEBUG_SANEI_SCSI=128
SANE_DEBUG_MICROTEK2=128
export SANE_DEBUG_DLL SANE_DEBUG_NET SANE_DEBUG_SANEI_SCSI
SANE_DEBUG_MICROTEK2
exec $SANE_DIR/sbin/saned 2> $SANE_DEBUG_LOG
This way I can see everything that saned is trying to do as it goes along
its merry way. Guess what?! After putting this wrapper in place everything
works great!!!!
Here's the output from the same scanimage device list command above after
making one change to inetd to use the wrapper instead:
device `microtek2:/dev/sga' is a Microtek ScanMaker X6EL flatbed scanner
device `net:localhost:microtek2:/dev/sga' is a Microtek ScanMaker X6EL
flatbed scanner
I have to assume that there's some small bug somewhere that doesn't crop up
when the debug log is written. Perhaps using the debug log works the heap
or stack just enough that it doesn't blow? I don't know. It's not
intermittent, either; it works consistently without a problem. For now I'll
consider my problem "fixed," and hopefully others who've seen this same
problem can benefit from my wrapper script above.
No, this solution doesn't give me a full "warm-and-fuzzy," but it has me
able to perform network scans, so I'm not complaining. Let me know if
anyone figures out what the REAL solution is.
Thanks for the help,
Scott Wells
PS: For what it's worth, I am using tcpd to fire off the saned wrapper
script, but it's not a permissions problem. I've configured my host access
files to allow access from machines on my LAN.
> This behaviour is just totally bizarre. The server is trying to respond to
> a SANE_NET_INIT request, which must only happen once, after the connection
> has already been initialised OK. I have no idea why this behaviour is
> connected with the choice to start the server from inetd. If you can find
> a way to arrange for more DEBUG levels to be on when the daemon starts
> then that would help...
>
> Are you all running TCP wrappers? Not running TCP wrappers? Can people who
> have this problem say anything more about their setup? In particular I
> find it difficult to believe that this could be a Linux 2.0.3x problem,
> since I'm using 2.0.36 happily here.
>
> Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com