Closed debiantriage closed 4 years ago
Apologies, Alex. I have just realised I have raised this issue in the wrong place. I do not know how to rectify that.
Cheers,
Brian.
Hi Brian,
I need logs from the ipp-usb: /var/log/ipp-usb/*
Also, please ask user, does avahi daemon actually running:
$ ps ax | grep avahi
811 ? Ss 0:44 avahi-daemon: running [pony.local]
818 ? S 0:00 avahi-daemon: chroot helper
Hi Alex,
here are the logs for /var/log/ipp-usb/* 03f0-f22a-CNB1M5ZXCV-HP-Inc--HP-Laser-MFP-135a.log main.log
Thanks a lot for helping
-also Alex
Hi Alejandro,
very strange device. It offers IPP-over-USB support at the USB level (by offering bInterfaceProtocol 4) but refuses all standard requests with HTTP 404 Not Found
status.
Either it doesn't actually support IPP-over-USB, or it needs it to be manually enabled somewhere in the configuration. I've spent some time reading its manual, but can't guess so far.
Are you able to open printer's web configuration console in the browser: http://localhost:60000/
If this URL opens, could you please browse it a little bit, may be you will able to find something relevant.
I am unable to enter that link, The only thing that appears is: Invalid Request. Some Error
however, when I disconect the printer, the typical Unable to connect appears...
Show me the output of the following command:
curl -D - http://localhost:60000/
here it is:
HTTP/1.1 404 Not Found Cache-Control: max-age=0, no-store, no-cache Content-Length: 262 Content-Security-Policy: frame-ancestors 'self'; Content-Type: text/html; charset=utf-8 X-Frame-Options: SAMEORIGIN X-Xss-Protection: 1; mode=block Date: Sat, 22 Aug 2020 19:58:16 GMT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Sorry, seems that I can't help you too much in this case :-(
HP documentation also states, that USB-only incarnation of this model doesn't support AirPrint
You may really try to install proprietary drivers from the link you've already mentioned at launchpad
Thanks a lot Alex,
I tried making it work with the proper drivers installed, but ive had no luck. Is there any tutorial that might help that you know of?
If not, it is okay. I really appreciate your help tho
No, unfortunately I don't have such a manual, I'm sorry.
Looks like a re-branded Samsung with buggy firmware. Do alternative free software drivers, like SpliX or foo2zjs make it work? I hope these corner cases will stay rare and HP will fix the firmware (can also be remove 7/1/4 when AirPrint is not intended).
@MrDrHax, you perhaps need to prevent ipp-usb from blocking the device. If you do not have any other USB printer which needs ipp-usb connected, try uninstalling the ipp-usb package. Then try again with the Samsung driver.
@alexpevzner, as there is always buggy hardware around, we cannot live without quirk rules. The CUPS "usb" backend has a quirk rule directory, /usr/share/cups/usb/
. Perhaps you should do something similar for ipp-usb and sane-airscan. Files contain a list of USB IDs with one or more keywords telling at which point your software should behave different. Having a directory allowing more than one file, packages can add quirk rules. And having all in ASCII files users and admins can also easily add new quirk rules for debugging.
At https://answers.launchpad.net/hplip/+question/692531 @MrDrHax reports that the driverless command did not produce an output. It did go through my mind at the time that the device was not an IPP-over-USB device because driverless
uses ippfind
. In fact, not a single one of the USB-only modern devices I have data for is capable of IPP-over-USB. However, curiosity made me press on.
@alexpevzner. Even though ippusbxd was not running, I reckon it left the printer in an inconsistent state, which is why there wasn't a USB URI. @MrDrHax has now obtained one and has a functioning device using the vendor driver. I have come to the conclusion that the HP Laser MFP 135a is not an IPP printer. Thanks for your help.
@tillkamppeter. From /usr/lib/cups/backend/usb
:
"HP Laser MFP 131 133 135-138" "MFG:HP;CMD:SPL,URF,FWV,PIC,RDS,AMPV,PCLM,PWGRaster,EXT;
An interesting set of PDLs!
The set of PDLs once shows that it is a Samsung, supporting Samsung's proprietary SPL language. So it most probably also works with SpliX or foo2zjs. But the list also contains URF, PCLM, and PWGRaster, so the three Raster PDLs of driverless IPP printing. So I am wondering why this one does not do AirPrint. One should try it with ipp-usb (NOT ippusbxd as ippusbxd has problems).
I wouldn't have thought that AirPrint on a USB-only printer would be a significant selling point for people with an iOS device.
@tillkamppeter, we already tried with ipp-usb. Printer really have IPP over USB interfaces, and even HTTP server behind them, but to all requests, this server responds HTTP 404 Not Found
. Looks like IPP over USB technically present, but disabled due to marketing reasons. Note, the WiFi version of this printer does support AirPrint
@debiantriage, ippusbxd might still be running, but incorrectly shown by the systemctl list-units "ippusbxd*"
command. Due to inaccurate integration with systemd, for example. At this case it could keep USB interfaces open, effectively preventing vendor drivers from attaching to device.
I will implement in the ipp-usb a mechanism that allows adding such a devices as exceptions, so ipp-usb will not interfere with the vendor drivers. Probably as Till suggested, it will be implemented as a directory with human-editable "quirks" files.
Hi @debiantriage
I wouldn't have thought that AirPrint on a USB-only printer would be a significant selling point for people with an iOS device.
There is an Apple's list of USB-only devices that support AirPrint, at the end of this document:
Looks like IPP over USB technically present, but disabled due to marketing reasons.
I have a very, very dim recollection from 20+ years ago. Computers were sold with chip A or chip B inside as a CPU. Chip A machines were less expensive.
In fact, the only type of chip that production lines churned out was chip type B. Chip A machines had one pin on the chip B disbabled when a machine was built and sold.
I can believe marketing reasons.
I won't be surprised, if HW vendors pay some licensing fee for each AirPrint-capable device they have sold. So if they think that for some model this fee exceeds benefit from supporting the AirPrint, they may decide to disable it.
I've even seen the amazing device, HP LaserJet M1536, which supports useless WS-Print (useless, because it supports IPP as well, and Windows perfectly prints to the IPP printer), but doesn't support WS-Scan. So for this device, all price of having WSD support was paid, without any benefit gained.
Latest version of ipp-usb
blacklists this device, using newly added "quirks" mechanism. So it is not longer the sane-airscan
issue, closing it here
Hi, Alexander
I tested the blacklists on my Canon MF745/746C whose DNS-SD name is dns-sd-name = "Canon MF745C/746 (cf:9d:6c)"
.
Firstly I added the DNS-SD name in the blacklist.conf as below, and then unplug and re-plug the USB, ipp-usb daemon still starts up.
[Canon MF745C/746 (cf:9d:6c)] blacklist = true
Then I modified the blacklist.conf as below, and retested. The ipp-usb daemon still starts up. Did I write the wrong device name?
[Canon MF745C/746] blacklist = true
After modified the device name as below, the "quirks" mechanism works. Even ipp-usb daemon still starts up, I can print by using Canon USB driver. Thanks for your work :-)
[Canon MF745C/746C] blacklist = true
Hi Tess,
the idea behind quirks is to instead of hard-coding special handling of some devices into the ipp-usb source code, put this "knowledge" into the collection of loadable files.
So the next time I will be working on fixing compatibility with some device, I can instruct user to create a quirks file and play a little bit with it content, without need to patch ipp-usb sources and rebuild it at user's side.
Quirks a bound to device model name (this string can be fetched from any USB device and not user-editable) instead of DNS-SD name, so changes in the device settings doesn't affect model-specific quirks.
I was actually in doubt, what to use to identify a device: model name or USB vendor:model numbers (in hex). For now I use model name, because it looks more friendly. May be I'll add a support of USB vendor:model numbers later, because it looks simpler to obtain (lsusb returns these numbers)
Thank a lot for your testing effort!
May be I'll add a support of USB vendor:model numbers later, because it looks simpler to obtain (lsusb returns these numbers)
Actually, the USB vendor:model number is easyer to obtain. I have a little query: I have two iR-ADV C5550 in my office. Both of their model names and their USB vendor:model numbers are identical. It seems the quirks can not distinguish the two devices.
But quirks actually don't need to distinguish. The purpose of quirks is to keep workarounds of hardware-specific bugs in a editable "database" instead of hardcoding it directly into the executable. If you have two similar devices, bugs should be the same and workarounds should be the sane too.
All right, waiting for supporting USB vendor:model numbers in the quirks :)
Hi, Alexander:
I feel a little confused those days. My Canon MF745 is connected by USB. I use airscan + ipp-usb to scan. But when I want to use Canon printer driver to print, I must change the blacklist.conf and replug the USB. It’s very inconvenience. But I can't think of a better way☹️. Do you have any idea to use the scanning and printing at the same time?
Hi Tess,
glad to hear from you!
printing should also work via ipp-usb
in a driverless mode (instead of proprietary USB driver). If it doesn't, we can ask @tillkamppeter to help.
At first I used the driverless driver, but I found vendor printer diver supplies more features, such as Department management, localization glossary and so on.
Hard to say, what can I do with it. ipp-usb on startup "takes" all USB interfaces that implement IPP over USB protocol (Class 7, Protocol 4, if you'll look to lsusb -v
output).
Depending on actual printer, these interfaces may or may not be shared with other functions (such as standard printing). In USB terms it is called "alternative configuration", every USB interface can be switched to any alternative configuration it supports, but simultaneously alternative configurations cannot be used. At this case, these functions will not be available while ipp-usb us running.
There are actually not to much IPP-over-USB interfaces available, typically 2 or 3, so I cannot leave a couple of them unused "just in case". And I don't want to allocate interfaces dynamically, on demand, because it may happen that in the time when I need an interface, proprietary driver has locked it, and I have no way to ask it to unlock.
@tillkamppeter, is it possible to use advanced features of the proprietary driver with the driverless driver? Will manual importing of the proprietary PPD file help at this case?
Hi, Alexander
Thanks for your explanation, I got the reason. I am considering to write a script to change the blacklist.conf automatically.
Hello Alex,
I have been helping a user at https://answers.launchpad.net/hplip/+question/692531. The 135a is unusual in that it is not supported by HPLIP software but by the Samsung Unified Linux Driver.
The later cannot be used to set up a print queue because, for some reason, Alejandro cannot get a USB URI. The device appears to understand IPP-over-USB (Message #10) and ipp-usb also thinks the same (Message #13). However, avahi-browse does not give what I would expect (Message #17).
Any ideas?
Thanks for any consideration,
Brian.