Using IPP: Unable to get printer status

[guillaumesoucy94]

Hello,

I cannot print using IPP with my new Canon G620 printer, "Unable to get printer status" occurs when sending a print job.

My other printers works just great using IPP, other printers are mainly Brother and Pantum.

I was able to successfully add the Canon printer to CUPS running remotely, port forwarding are in place to forward the traffic back to the printer on the local network.

If I'm adding the printer without passing by the remote CUPS service, meant using the local CUPS running from Linux Mint, by entering it's local IP, I can send every print jobs that I sent to the printer.

It's working locally but not remotely.

Thanks,

Guillaume

[michaelrsweet]

We'll need the CUPS error_log with debug logging enabled (cupsctl --debug-logging) showing the print job not getting through.

That said, port forwarding will probably not work reliably since the printer might not like the hostname/address you are passing over the tunnel (foreign address). If the printer does hostname validation (to protect against DNS rebinding attacks) then it will think you are trying to bypass the local network security and fail the request.

But let's see that log and it might tell whether the printer is rejecting the request for this reason...

[guillaumesoucy94]

Hello,

I enable the debug logging, and the error_log is attached to this message.

error_log.txt

It is quite long, this is the part displaying the error message:

error_log2.txt

Also, when printing from my Android phone, on the same network just to try to see what will happen, the phone display these two notifications:

Tapping Accept make the print to go through. It is possible that the error when printing remotely is related to a certificate?

Thanks,

Guillaume

[zdohnal]

It could be - do you know if Android connects to your print server, or to your printer? I recall there was an issue about certificates in the past, so it might be related.

Either way, even the longer debug does not show where IPP backend on your client connects to, so we're not able to tell if you do connect to the server or to the printer. At least start of the job would be great to see.

And IIUC you have client - server - printer environment, so the corresponding debug logs from cups on the server help a great deal, if you talk with server.

[guillaumesoucy94]

It could be - do you know if Android connects to your print server, or to your printer? I recall there was an issue about certificates in the past, so it might be related.

Yes, in the screenshot, the Android phone was connecting directly to the printer, I made it that way just to see what will the result.

For the certificate, is there anything I should do with that part, what do you recommend me?

Either way, even the longer debug does not show where IPP backend on your client connects to, so we're not able to tell if you do connect to the server or to the printer. At least start of the job would be great to see.

I'm not sure but we can see the error message stated above in the logs. The G620 seem to attempting to connect.

And IIUC you have client - server - printer environment, so the corresponding debug logs from cups on the server help a great deal, if you talk with server.

Yes, the logs are the one from the server running cups. Here is thr topology:

Workstation is sending print job -> CUPS running in my server room is getting the job (network is isolated, only electrical is common as it is on the same property but in a different structure) -> Printer (via port forwarding)

NB. Printers are spreaded across my three locations.

NB. That current topology works great since years with Brother and Pantum printers. My Canon MX492 injet also work with that topology.

Thanks

Guillaume

[zdohnal]

For the certificate, is there anything I should do with that part, what do you recommend me?

I'm not sure how printing exactly works on Android, but AFAIK in Linux CUPS generates DBUS event about certificate changed, which should be picked up by desktop environment and generate notification about certificate has changed - and if user confirms it is okay, application should save the new certificate, so printing should continue after that. Do I get it right, @michaelrsweet ?

So if you see this every time you print, your printer either changes cert, or Android does not save it, or there is something in the middle.

I'm not sure but we can see the error message stated above in the logs. The G620 seem to attempting to connect.

AFAIK the printer does not initiate the communication, so printer does not attempt to connect to cupsd or IPP backend - IPP backend on the server initiates the connection and I don't see URI what it tries to connect to - the only job related logs are those about getting supported attributes failing with bad-request, which results into error you see.

Can you upload .txt file with logs so I can see what the backend connects to? You can provide the part of the logs where the job starts and then gets several first error messages.

On the top of that, please upload unencrypted traffic which happened between your server and the printer, so we can see we don't send something weird to the printer.

Workstation is sending print job -> CUPS running in my server room is getting the job (network is isolated, only electrical is common as it is on the same property but in a different structure) -> Printer (via port forwarding)

I'm curious about this, since I haven't heard about someone doing it for printers - so you implement port forwarding on your server via iptables, so you install the printer with different hostname/IP on the server, but when communicating with printer, iptables translates the hostname/IP to the correct hostname/IP where the printer listens to? Or is there is another network member doing the translation?

NB. That current topology works great since years with Brother and Pantum printers. My Canon MX492 injet also work with that topology.

As Mike mentioned, it can be a printer specific.

[michaelrsweet]

@zdonal WRT certificates, you are correct. However, none of the logged requests are encrypted.

[guillaumesoucy94]

For the certificate, is there anything I should do with that part, what do you recommend me?

I'm not sure how printing exactly works on Android, but AFAIK in Linux CUPS generates DBUS event about certificate changed, which should be picked up by desktop environment and generate notification about certificate has changed - and if user confirms it is okay, application should save the new certificate, so printing should continue after that. Do I get it right, @michaelrsweet ?

So if you see this every time you print, your printer either changes cert, or Android does not save it, or there is something in the middle.

I'm not sure but we can see the error message stated above in the logs. The G620 seem to attempting to connect.

AFAIK the printer does not initiate the communication, so printer does not attempt to connect to cupsd or IPP backend - IPP backend on the server initiates the connection and I don't see URI what it tries to connect to - the only job related logs are those about getting supported attributes failing with bad-request, which results into error you see.

Can you upload .txt file with logs so I can see what the backend connects to? You can provide the part of the logs where the job starts and then gets several first error messages.

On the top of that, please upload unencrypted traffic which happened between your server and the printer, so we can see we don't send something weird to the printer.

Do you mean the access logs file instead? nor the error_log ?

What I sent previously the error logs file.

Workstation is sending print job -> CUPS running in my server room is getting the job (network is isolated, only electrical is common as it is on the same property but in a different structure) -> Printer (via port forwarding)

I'm curious about this, since I haven't heard about someone doing it for printers - so you implement port forwarding on your server via iptables, so you install the printer with different hostname/IP on the server, but when communicating with printer, iptables translates the hostname/IP to the correct hostname/IP where the printer listens to? Or is there is another network member doing the translation?

NB. That current topology works great since years with Brother and Pantum printers. My Canon MX492 injet also work with that topology.

As Mike mentioned, it can be a printer specific.

I forgot to tell in my initial post that accessing the printer via its IPP port is giving the following error message in the browser, locally via another computer or remotely over the internet:

"403 Forbidden

Now, connection is crowded.Please reaccess after a while"

Concerning the setup or topology, it's because I'm working with thin clients and a server (with desktop environment). The server-workstation is not on the same network than thin clients, printers of a given site are on the same network than the thin clients.

Let's say I'm on a thin client on site 01. I'm connected to the server-workstation. So now it is time to print a document of some kind. I click on the corresponding printer from the printing dialog so the print job is sent to the print server (on the same network than the server-workstation. Then the print job is routed to the printer at the site 01 using the site 01 hostname and the TCP port that forward the traffic to the G620 printer.

The port forwarding is done in the ISP router.

I know this is not a sort of conventional setup but it's working well for a decade now. :-)

Guillaume

[guillaumesoucy94]

Hello,

I think that to something, I will add a locally hosted CUPS server that the remote CUPS will send jobs to. This local CUPS instance will send the job to the printer so the printer will technically receive the job from another host on the network, instead directly from another host from the internet, so if it was an issue caused because the job is originating from a different hostname, it should theoretically stop showing the error and start printing?

Will see...

Guillaume

[guillaumesoucy94]

It works with a local CUPS in between...

So, it might be related to the hostname mismatch. 😞

Is there a hack to bypass the mismatch, or is the local CUPS the only trick?