Hi, yesterday I reported a bug ( tracker #313760 ) with my network scanner (WP-4535-DWF) and the ADF
With enabled debug i got following output with scanimage -d epson2 --source 'Automatic Document Feeder' -b ----------------------- snipp ------------------------ [epson2] e2_recv: size = 14, buf = 0x7fffb4873400 [epson2] sanei_epson_net_read: wanted = 14, available = 14 [epson2] sanei_epson_net_read: full read [epson2] e2_recv: expected = 14, got = 0 [epson2] e2_txrx: rx err, Error during device I/O [epson2] sane_epson2_start: start failed: Error during device I/O scanimage: sane_start: Error during device I/O [epson2] close_scanner: fd = 3 ------------------------ snapp ------------------- For me it looks like the driver receives the header from the scanner which tells, that there will be 14 bytes of payload follow. But while reading this payload no data is received. As I mentioned in the bug report, I think the scanner sends the header and the payload in two different tcp-messages. My computer seems to be to fast. After reading the header, the driver tries to read the payload immediatly before it arrives on the tcp-queue. So the recv()-call return with an error and the driver delivers the IO-error In the above situation ( call recv() without data in the tcp-queue) the recv() call returns with -1 and with errno = EAGAIN. In this case everything seems to be alright but we have to wait and call recv () a second time. As a solution I changed 'sanei_tcp_read'. I added a small loop which, in case of EAGAIN, waits for 0,2 seconds and calls recv() again. After 5 retries it returns with the error (take a look at diff in bug report). This works fine an I got the debug message that tells me that 'sanei_tcp_read' waits for one cycle. ------------------- snipp --------------------------------- [epson2] e2_recv: size = 14, buf = 0x7fff60ec1020 [sanei_tcp] sanei_tcp_read: bytes received 12 [epson2] sanei_epson_net_read: wanted = 14, available = 14 [epson2] sanei_epson_net_read: full read [sanei_tcp] sanei_tcp_read: bytes received -1 [sanei_tcp] sanei_tcp_read: got error Resource temporarily unavailable(11) [sanei_tcp] sanei_tcp_read: waiting 4 [sanei_tcp] sanei_tcp_read: bytes received 14 [epson2] buf[0] 02 . [epson2] buf[1] 12 . -------------------- snapp -------------------------------- Since this is a change in the basics, which may have an impact on all tcp-network drivers, this sollution should be discussed in more detail. As Alessandro Zummo mentioned in the bug report, another solution is to use a blocking socket. But IMHO this changes the behaviour of every code, which accesses this socket. Handling the EAGAIN seems to me a much smaller change, with low unwanted impact on other code. Kind Regards Dieter
