Preview or Scan via WSD works only once

[dkadioglu]

Preview or Scan via WSD on my OKI MC 362dn works only once. After that one successful command, sometimes restarting the printers NIC or sometimes only rebooting the printer leads to another successful command but, again only once until restart. After a single successful command, for all further commands I get an error message telling me, that the Device is busy.

OS: Arch Linux, fully updated MFD: OKI MC 362dn, Firmware A13.80_0_5

As I have no clue, if this could be the fault of the MFD, the OS or Airscan, I'd like to kindly ask you, what information/logs would be helpful.

[dkadioglu]

I just did two scans in a row, as expected, the first worked, the second failed. Please find attached the traces separated into 'good' from the first successful scan and 'bad' from the second failed scan. I would be happy about any sort of help in investigating this further. Thanks in advance. airscan.tar.gz

[alexpevzner]

Hi!

sorry for very long delay in response. Is this issue still relevant?

[dkadioglu]

Hi, thanks for asking. Yes, unfortunately, this is still relevant. Just tried it again and the issue is still the same, i.e. an operation (e.g. Preview scan via Skanlite) runs only once, afterwards any other command is not successful and I have to restart the network stack of the device. If you need some new logs or any further info, please ask.

[yellowpookie]

Have the same issue with Oki MB471 Oki FW: A14.90_0_4 (latest) Debian 12.5 Sane-airscan git latest

Trace logs attached first_attempt.log second_attempt.log

Ситуация такая же как у автора. Первое сканирование проходит, вне зависимости от источника, любая попытка сканирования после, с любого источника, отвечает Device busy

[alexpevzner]

Hi @yellowpookie,

could we please speak English here, please, so other people will be able to read our discussion?

Can you build sane-airscan from sources, for debugging purposes? There is no need to make install it, it would be enough to locate where libsane-airscan.so.1 is installed on your distro (usually it is /usr/lib64/sane/libsane-airscan.so.1 or /usr/lib/sane/libsane-airscan.so.1) and replace it with symbolic link to the libsane-airscan.so.1 in your build directory).

Once you've succeed doing that, please re-run your tests and attach the new logs. Then I will be able to try to do something with this issue.

[yellowpookie]

@alexpevzner sure. sane-airscan already built from sources, logs above captured from latest version

[alexpevzner]

Hi!

Please update, rebuild and retest. And regardless of test result, please show me updated logs.

[yellowpookie]

@alexpevzner issue isn't fixed this time. Same behavior, as I can see. Logs: first_attempt.log first_attempt.tar.gz second_attempt.log second_attempt.tar.gz

[alexpevzner]

Hi @yellowpookie,

once again, please.

And the question: what do you need to recover the scanner? Reboot it? Wait for some time?

[yellowpookie]

@alexpevzner reboot MFP itself, or reboot network stack from web interface by action called "Reset Network Card". It restarts all network services on MFP, I guess, dhcp-client and web-server for sure.

Looks the same fourth_attempt.log third_attempt.log

[alexpevzner]

Can you also run tests with ADF, please?

[yellowpookie]

@alexpevzner sorry for delay, MFP is remotely located. ADF and ADF Duplex can work continuously, as I can see. ADF Duplex have issue with page size, like I guess. Flatbed still get stuck after first attempt. ADF: adf-first.log adf-first.tar.gz adf-second.log adf-second.tar.gz adf-third.tar.gz adf-third.log ADF Duplex: adf-duplex-first.log adf-duplex-first.tar.gz adf-duplex-second.log adf-duplex-second.tar.gz adf-duplex-third.log adf-duplex-third.tar.gz

[hegdi]

Same issue here with Oki MC332. ADF works. Flatbed once basically renders WSD useless, till reboot/reset of the MFP. Not even airscan-discover can find it anymore. I have the device at hand so I can provide you with test results, if helpful. I can also provide you with pcap traces from Windows showing Flatbed scanning repeatedly if you want to have a look. If I can do something to assist with this issue feel free to ask.

[hegdi]

Well to impatient to wait, so I fixed it myself. I would say more like a proof of concept or works for me, but regardless. I couldn't be dare to make a pull request for a single line so I put it here, well aware that this is a shortcut. My apologies.

diff --git a/airscan-wsd.c b/airscan-wsd.c
index 008248b..0ca9f64 100644
--- a/airscan-wsd.c
+++ b/airscan-wsd.c
@@ -1239,7 +1239,7 @@ proto_handler_wsd_new (void)
     wsd->proto.status_query = wsd_status_query;
     wsd->proto.status_decode = wsd_status_decode;

-    wsd->proto.cleanup_query = wsd_cancel_query;
+    wsd->proto.cleanup_query = wsd_load_query;
     wsd->proto.cancel_query = wsd_cancel_query;

     wsd->proto.test_decode_devcaps = wsd_test_decode_devcaps;

So basically Windows always sends a second RetrieveImage response after the first. And Oki seems to require this. With this change in place scanning works flawlessly with ADF/ADF Duplex and Flatbed.

Thanks for your work, I really appreciate your effort.

[yellowpookie]

That patch work for Oki MB471, but breaks HP LaserJet Pro MFP M125nw over WSD, at least.

[hegdi]

Fair point, I don't have any other device to test. After checking the specification the intended behavior is pretty clear. Windows Driver specification

If Format specifies a single image format and the value of ImagesToTransfer is 0 or greater than 1, the client will send repeated RetrieveImageRequest operation elements until the Scan Service replies with a ClientErrorNoImagesAvailable fault or until the ImagesToTransfer value is met.

Currently ImageToTransfer is either zero or some large number so for Flatbed it should be exactly one.

[hegdi]

This should be fixed in #343 seems I'm to stupid to link it directly

[alexpevzner]

@yellowpookie,

what happens to HP LaserJet Pro MFP M125nw with @hegdi's patch? Can you give more detailed explanation with logs?

@hegdi,

your patch changes PROTO_OP_CLEANUP to PROTO_OP_FINISH which effectively disables cleanup step and separately you change cleanup from cancel to RetrieveImage. What is correct of these two changes?

[yellowpookie]

@alexpevzner I'll test today both patch above and #343 and post detailed information here.

[hegdi]

@alexpevzner,

Let me try to clarify, the patch in my post wasn't fixing the root cause it only allowed me to proof my suspicion. According to the Windows Driver Specification if you send a RetrieveImageRequest with a ImageToTransfer of zero, indicating continuous scanning, you need to do so until the device answers with ClientErrorNoImagesAvailable.

This is how it is handled in the ADF case, which worked even before your patch. That basically also means if the number of scans is known and fulfilled like ImageToTransfer equals 5 and this is the 5th image retrieved you don't need to send another RetrieveImageRequest cause you know the sequence is over.

Now let's come to the way it is implemented currently ( as in your master ). ADF case is just fine as it already follows this logic. But the Flatbed case was sending a ImageToTransfer of zero too, which would indicate more to come for the MFP and requiring another RetrieveImageRequest. That is what I did clumsily in my patch, to see if that makes the MFP happy.

That is why I called it a Proof of Concept in the patch post. Now to my pull request #343. As my explanation hopefully made it clear the right thing to do is send a ImageToTransfer of 1 if using the Flatbed. Which tells the MFP the sequence is over and no additional RetrieveImageRequest is needed.

So as your change introduced a forced CancelJobRequest after every scan but didn't fix the problem. I wanted to get rid of the forced cancel but keep, your also introduced, sending cancel in different error cases.

So my pull request should:

• disable the forced cancel after every scan
• set the ImageToTransfer number properly

As a side note, the forced cancel returns with invalid job id, if the job is over (ImageToTransfer count reached).

Hopefully my explanation helps.

So as a summary, #343 is the real deal. My patch is not needed anymore, neither is your forced cancel.

[alexpevzner]

@hegdi,

my forced cancel came from the eSCL experience, where some devices really want it. My Kyocera ECOSYS M2040dn one of such devices, it feels itself busy after the scan for about a minute, which is very annoying. Cancel helps.

But WSD firmwares behave differently, and cancel seems to be useless here.

You #343 PR looks correct for me, I'm going to accept it. But I still want some clarification from @yellowpookie regarding HP LaserJet Pro MFP M125nw.

BTW, your commentary regarding affected devices contradicts with your change to README.md. You've mentioned OKI MC332dn, MC362dn and MB471 as affected, but added MB471 and MC332 as supporting eSCL. Please, update there.

[hegdi]

@alexpevzner,

Oops... wrong column. Updated!

@yellowpookie,

343 is enough for testing, no need to bother yourself with the earlier patch. Thank you for testing!

[hegdi]

@yellowpookie,

ADF Duplex have issue with page size, like I guess.

Yes the page size is wrong, scaling and/or cropping issue. Either cut off or squished. But that is a topic for another issue.

[yellowpookie]

@alexpevzner #343 works with Oki MB471 and HP LaserJet Pro MFP M125nw both.

[alexpevzner]

OK, lets merge...

[yellowpookie]

@hegdi @alexpevzner Both MFP tested today frequently, without any issues. Thank you both for great work!

[dkadioglu]

@yellowpookie @hegdi @espindola @alexpevzner thank you very much for testing and/or contributing fixes for this issue! With the recent changes, this works for me with my MC362 now, too!