[sane-devel] network scanner problems

[Guido Socher]

Hi,
thanks very much these were very useful hints.
I think I have now a more complete picture of what is ongoing here:
- the very cause of the problem is not in the net backend
  but even lower.
- The net backend crashes because the saned program terminates first.
- saned terminates abnormally because of problems in the hp backend
  or the kernel.
  It gets a SIGPIPE when trying to write data to the scanner while
  the actual scan is already done. The data that it tries to write
  seem to be some option settings.

The solution that I have made in more a work arround because
I could not really figure out how to solve the case of the problem.
I just catch the sigpipe in saned:

static void
ooch (int signum)
{
        if (signum)
                syslog (LOG_ERR, "received signal %d in ooch\n", signum);
        signal(signum,ooch);
}

signal (SIGPIPE, ooch);

This leads to this:
Aug 10 23:10:17 easy kernel: usb_control/bulk_msg: timeout
Aug 10 23:10:37 easy saned[20456]: received signal 13 in ooch
Aug 10 23:10:37 easy saned[20456]: do_scan: write failed (Broken pipe)
Aug 10 23:10:57 easy kernel: usb_control/bulk_msg: timeout
Aug 10 23:11:11 easy saned[20456]: received signal 13 in ooch
Aug 10 23:11:11 easy saned[20456]: do_scan: write failed (Broken pipe)

...but otherwise scanning works ok and it does not crash anymore.

Who feels actually responsible for the hp backend? 

Regards
 Guido

On Tue, Aug 07, 2001, henning at meier-geinitz.de (Henning Meier-Geinitz) wrote:
> 
> As far as I see only the data connection is closed, not the normal
> control connection. But I'm not an expert in the net protocoll.
> 
> > The connection is closed in the sane_read() function in
> > net.c because it executes this code:
> >   if (s->bytes_remaining == (size_t) - 1)
> >         {
> >           char ch;
> > 
> >           /* turn off non-blocking I/O (s->data will be closed anyhow): */
> >           fcntl (s->data, F_SETFL, 0);
> > 
> >           /* read the status byte: */
> >           if (read (s->data, &ch, sizeof (ch)) != 1)
> >             ch = SANE_STATUS_IO_ERROR;
> >           do_cancel (s);
> >           return (SANE_Status) ch;
> >         }
> > 
> > That is s->bytes_remaining is -1 and then do_cancel(s) is
> > called which closes the connection.
> > Next xscanimage (ignoring the closed connection) tries 
> > to set some control options using this
> > closed connection and that is where the sigpipe is received.
> 
> I don't think the problem is the closed data socket. I'm not sure if
> something like (size_t) -1 is portable but it doesn't seem to be a
> problem here.
> 
> > The interessting thing is that the scan as such is ok, i.e I can
> > see the full picture in the preview for a second.
> > 
> > I have the feeling that the -1 record length is used as a special
> > value to signal the end of the scan and unfortunately net.c
> > thinks that this is an error. Is that possible?
> 
> It's the end of the scan (no more data) and the data socket is closed.
> I have just tried this with the Mustek and mustek_usb backends. No
> sigpipe or other error.
> 
> > It think that is is the case because scanning directly without
> > the network inbetween works perfectly. 
> 

-- 
The place for Linux documentation in your own language.
http://www.linuxfocus.org