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.
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?
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.
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…
DNS-SD would certainly be useful for automatic printer discovery and easier setup. However, discovery and printing are two separate parts of the problem.
As PulkoMandy explained above, Haiku’s existing IPP transport uses its own rather broken HTTP implementation. This means that printing may still fail even when the printer address, port 631 and the correct IPP queue are already known.
I recently approached the problem from the Linux side and looked at what is actually sent to an IPP printer on port 631. Based on that, I developed an experimental userspace workaround called Haiku IPP Print Bridge.
The bridge currently works without DNS-SD. The printer address and queue are entered manually, and it sends a proper IPP Print-Job request directly to the printer. PDF and PostScript files are converted to JPEG pages with Ghostscript before being submitted.
It has been tested successfully with Brother printers, and another user has successfully printed a test page on an HP Envy printer from Haiku hrev59048.
So DNS-SD would improve convenience and automatic discovery, while a working and compatible IPP/HTTP transport is still required for the actual print job.
Please don’t post updates to old threads like this, you already have your thread open, and this reply does not help with the problem at all. Haikus print system is still where it was… and as mentioned there is a realistic path forward, nobody has done it yet.
Seeing as you did not provide sourcecode for your project I don’t see how this would help us improve Haikus ipp printing support.
(also please don’t sign your posts, that is explicitly mentioned in the forum guidelines)