Hi Louis,<div><br></div><div>Sorry, but after fighting with this scanner for all of last weekend and realizing just how pitiful Canon's Linux support is, I returned it and bought an HP instead. The HP works perfectly with Sane.</div>
<div><br></div><div>I do have quite a few debug logs recorded and it looks like the "unknown1" value in the job details response is always zero. I actually added some code to write out the members of the struct in addition to the raw bytes, so this is pretty easy to grep for.</div>
<div><br></div><div>I've attached two logs. In the first one, the scanner successfully scanned three pages (and then refused the connection for the fourth page, because there was no physical fourth page). In the second one, the scanner refuses to connect on the first page, presumably because it has been left in a bad state.</div>
<div><br></div><div>Of course, since I don't have this scanner anymore I don't expect anyone to actually look at these.</div><div><br></div><div>-Kenton</div><div><br><div class="gmail_quote">On Sat, Jan 22, 2011 at 7:32 AM, Louis Lagendijk <span dir="ltr"><<a href="mailto:louis@lagendijk.xs4all.nl">louis@lagendijk.xs4all.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Sun, 2011-01-16 at 02:04 -0800, Kenton Varda wrote:<br>
I leave your first question for Nicolas to answer. I don't understand<br>
the backend well enough to dig into this part. sorry for the late reply,<br>
I have been out of the country for a few days and busy with work...<br>
<div class="im"><br>
> Unfortunately, there is another, less-deterministic problem. It seems<br>
> that the scanner very frequently refuses sane's TCP connections:<br>
><br>
><br>
> [pixma] Reader task terminated<br>
> Scanned page 1. (scanner status = 5)<br>
> Scanning page 2<br>
> [pixma] Reader task id=14568 (forked)<br>
> [pixma] Reader task started<br>
> [pixma] sanei_bjnp_activate (0)<br>
> [pixma] udp_command: Sending UDP command to <a href="http://10.0.1.22:8612" target="_blank">10.0.1.22:8612</a><br>
> [pixma] bjnp_open_tcp: Can not connect to scanner: Connection refused<br>
> [pixma] sanei_bjnp_deactivate (0)<br>
> [pixma] udp_command: Sending UDP command to <a href="http://10.0.1.22:8612" target="_blank">10.0.1.22:8612</a><br>
> [pixma] [pixma] Reader task terminated: EINVAL<br>
> read_image():reader task closed the pipe:0 bytes received, 10718400<br>
> bytes expected<br>
> scanimage: sane_read: Invalid argument<br>
> Scanned page 2. (scanner status = 4)<br>
> [pixma] pixma_close(): Canon PIXMA MX870<br>
> [pixma] sanei_bjnp_close(0):<br>
><br>
><br>
> It's hard to pin down a pattern describing when this happens, but:<br>
><br>
><br>
> - It never happens if the scanner was just powered on (and had time to<br>
> boot). Or in other words, power cycling the scanner fixes problems,<br>
> suggesting that the scanner is getting into a bad state.<br>
><br>
</div>I have seen cases before where we got stuck opening a TCP connection<br>
where the scanner got confused. Your guess is most likely correct.<br>
<div class="im">><br>
> - It always happens when the ADF runs out of paper. sane appears to<br>
> form a new connection for each page. After the last page, sane tries<br>
> to connect again even though there are no more pages, and this<br>
> connection always fails AFAICT. This causes scanimage to exit with an<br>
> error code even though technically it completed its task successfully.<br>
><br>
><br>
> - After having completed a batch, the scanner is sometimes (but not<br>
> always) left in a state where all further connections are refused<br>
> until the device is power-cycled. Sometimes the device will recover<br>
> from this state magically without a power cycle, if I retry a few<br>
> times. Sometimes running Scangear MP can revive the device from this<br>
> state, but not always.<br>
><br>
><br>
> - I changed the TCP connection code to retry once, and the result is<br>
> even odder: The retry sometimes succeeds, but then the scanner<br>
> apparently does not reply to any requests on the new connection.<br>
><br>
</div>I has a look at the bjnp code again, but can not check details as some<br>
of the information is missing. Can you please get me a log file with<br>
log-level 14 or (maybe even better) a wireshark trace? I am especially<br>
interested to see what the "unknown1" value of the last UDP command is<br>
before we try to open the TCP connection. I have never seen it set, but<br>
that may be due to the fact that I don't have an ADF....It may be that<br>
your scanner uses that unknown stuff to signal that is is not ready to<br>
read more data. It may also be that we need to teach the higher level of<br>
the backend when no more pages will be available. Does a USB connection<br>
behave any better?<br>
<div class="im">><br>
> I tried comparing network dumps between SANE and Scangear MP, but they<br>
> were completely different. Scangear MP appears to make only one TCP<br>
> connection for the whole batch, rather than one per page.<br>
><br>
</div>That is due to the fact that the backend closes the bjnp connection<br>
(like if does for the USB-connection).<br>
><br>
> Any ideas?<br>
Please provide some detailed traces so we can see what is happening<br>
<br>
best regards, Louis<br>
<br>
</blockquote></div><br></div>