That comes from the remote frontend closing the connection.
> The SIGPIPE is weird.
> The other end of the network (scanimage -L, with just the net driver active):
Here is the network transfer:
> write(24, "\0\0\0\0\1\0\0\3\0\0\0\4wim\0", 16) = 16
A SANE_NET_INIT request.
> read(24, "\0\0\0\0\1\0\0\3", 8192) = 8
Answer looks good.
> write(24, "\0\0\0\1", 4) = 4
> read(24, "\n\nScanner attributes from device"..., 8192) = 43
There we go. For some weird reason the saned sends textual data via the
net stream. That looks like a bug in the backend or the saned.
Seemingly the driver gives additional info to stderr, which gets redirected
over the Network, and causes havoc in the binary protocol.
> More strangeness: If I do saned -d, it works (just once though)...
> I was just thinking, is this due to the text appearing at startup.
Yes. Definitely.
> somehow saned started from inetd seems to also send this to the client,
> where with saned -d you only get to see the result of the probe, while
> the text is on the console where I started saned -d.
O.K. that indicates, that the backend for some reason sends that diagnostic
stuff to stderr which seems to be mapped to the network connection by inetd
what causes the problem. As a workaround I suggest to use a script saned.in:
#!/bin/bash
exec saned 2>/dev/null
which will avoid the stderr stuff to mix up with the net stuff.
IMHO the backend should be fixed not to spit out such diagnostic stuff
unless told to specifically using a SANE_DEBUG variable or similar.
CU, ANdy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com