CAPT: no reply from printer

[MichaelVoelkel]

Hi,

first, thanks for providing a driver here.

I have successfully compiled and installed it and added my Canon LBP2900 as a printer. I can send documents to it via "lp test.txt" and access_log also says "200 315 Send-Document successful-ok" and also "200 309 Create-Job-successful-ok"

However, "lpstat -p" gets then stuck on "CAPT: no reply from printer".

I could not find anything towards this error message. I have put the debug level of CUPS to detail, but no other error message appears. Any ideas?

[agalakhov]

Hi,
I can only say that it's my misunderstanding of the CAPT protocol. Further reverse-engineering is needed. Unfortunately, I don't have the printer anymore, so I can't do it myself.

[MichaelVoelkel]

Hi, I see. Any hints on how to reverse-engineer here? I program myself but have no experience with drivers. Probably, out of reach but who knows... Best regards, Michael

…

Am 29.05.2017 um 12:35 schrieb Alexey Galakhov ***@***.***>: Hi, I can only say that it's my misunderstanding of the CAPT protocol. Further reverse-engineering is needed. Unfortunately, I don't have the printer anymore, so I can't do it myself. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[agalakhov]

This is not that hard, but there is a lot of guessing. We send commands to the printer, each command is in the form i.e. 0xA0 0xE0 0x... 0x.... It starts with some 16-bit code, then comes the 16-bit length followed by the body. If you're familiar with RIFF (Wave) format, this is very similar. The printer's reply has the same format. We know the meaning of many commands (look at the SPECS file in the repo), but looks like we misunderstood some of the status bits.

The "No reply from printer" error means that we sent a message to the printer and never got a reply. This may be just a bug (waiting while nothing was sent), but most likely this is caused by sending something to the printer that is not ready to receive data. The readiness is checked using the status flags in the previous printer reply. If the printer is "not ready", we must not send anything except for status queries. Sending while not ready seems to hang the printer's CPU. There is some mysterious command at the end of the job, and we did not issue it correctly.

We analyze the protocol by sniffing the behavior of Windows driver using some USB sniffer/debugger (SnoopyPro, USBPCap, Wireshark etc.) while printing simple and predictable things. Unfortunately the precise meaning of many commands is still unclear.

(And my general recommendation is NOT to buy any CAPT printers. It's the only printer protocol I know that uses bidirectional communication all the time and relies heavily on the driver. All other printers, even the GDI ones, just use some kind of streaming protocols, in the worst case just image streams. The CAPT behavior is very, very unusual for a printer.)

Regards,
Alexey