IPP printing produces transport error

Help
1

I just tried to setup my OKI Data CD321dn using IPP which works from Linux with the URL supplied by the OKI web interface:
http://192.168.0.xxx:631/ipp (also tried alternative URLs provided like an ipp:// URL)
but cannot get printing to work.

It either says “client error” (for the URLs that should work) or refuses to connect (for other attempts with alternatives).

In the system log, I found these strange errors:

KERN: runtime_loader: Cannot open file /boot/home/config/add-ons/Print/transport/IPP (needed by <NULL>): No such file or directory
KERN: runtime_loader: Cannot open file /boot/system/non-packaged/add-ons/Print/transport/IPP (needed by <NULL>): No such file or directory

The UI then displays an empty info alert, followed by a normal error alert.
Will try with the alternative approach suggested in another thread using JetDirect, but would really love to have native IPP support with the correct driver.

Lastly, it’s a bit weird/cumbersome that you can only specify the IPP URL when trying to print something, this should be part of the settings so you can instantly configure and test it.

1 Like
2

Since this is home/config and system/non-packaged that seems benign to me, it is checking if there is an unpackaged version of the driver.

Why it prints those lines then seems strange to me.

Do you have system/add-ons/Print/transport/IPP available? is it loaded?
(you can check with listimage)

1 Like
3 
   ID               Text               Data  Seq#      Init# Name
--------------------------------------------------------------------------------
 7588 0x000001b6363ca000 0x000001b6363e6000     0          0 /boot/system/add-ons/Print/transport/IPP

is available but I don’t know if it’s loaded, how do I check this?

2 Likes
4

What you printed shows that it is loaded.

The IPP driver currently uses a custom and rather broken implementation of http. It should be upgraded to use the “services kit” http implementation instead, then it will have at least some chance of talking with a printer. Currently it is not usable unless you have a very tolerant printer that will accept barely valid http requests.

2 Likes
5

Okay that sounds doable, will have a look, since it’s running in user land it should be easier to debug…

6

just stumbled over the PAPPL project, would this be a suitable stack we could work on and save us some pain? Not sure if it’s license compatible, but Apache seems close enough…

7

I don‘t think there is much work we meed to do apart from printer discovery, and the work there is mostly network discovery in general (via dns-sd)