Bug 238470 - print/cups: 2.2.10 Add dependencies for networked printing (avahi, nss_mdns)
Summary: print/cups: 2.2.10 Add dependencies for networked printing (avahi, nss_mdns)
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Tijl Coosemans
URL:
Keywords: needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2019-06-10 20:45 UTC by Ronald F. Guilmette
Modified: 2019-06-21 04:27 UTC (History)
2 users (show)

See Also:
tijl: maintainer-feedback+
koobs: merge-quarterly?


Attachments
current network configuration -- MFC-7860DW (38.01 KB, application/pdf)
2019-06-17 08:57 UTC, Ronald F. Guilmette
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald F. Guilmette 2019-06-10 20:45:43 UTC
The prerequsites list for the current cups-2.2.10 port/package apparently makes the dubious assumption that the user will only be printing to a non-networked, locally attached USB/serial/parallel printer.  As a result, the prerequsites list for the current cups-2.2.10 port/package fails to cause the avahi and nss_mdns ports/packages to be built and/or installed.

The result is that if and when the user attempts to actually use the installed CUPS port or package to print to a networked printer, much havoc, consternation, and confusion will ensue.  The subsequent failures, e.g. to either "add" a networked printer or to print to a networked printer, are both mystifying and difficult to rectify for users who are not already steeped in CUPS knowledge.
In short, the absence of avahi and nss_mdns from the cups-* prereqsites list is maximally user-unfriendly, specifically in the case where the user is or will be using a networked printer (which these days will be THE most common scenario).

For this reason, I strongly urge that avahi and nss_mdns be added to the list of prerequsites foe the cups-* package and port.
Comment 1 Tijl Coosemans freebsd_committer 2019-06-11 10:36:39 UTC
Cups already depends on Avahi and it finds network printers automatically.  When I press "Add printer" in http://localhost:631 it lists my network printer under "Discovered Network Printers":

* Photosmart Premium C309g-m [0C6718] (HP Photosmart Premium C309g-m)
* Photosmart Premium C309g (HP Photosmart Premium C309g-m)

When I select the first one and press Continue the connection string is:

Connection: dnssd://Photosmart%20Premium%20C309g-m%20%5B0C6718%5D._pdl-datastream._tcp.local/|HP Photosmart Premium C309g-m

So this is the configuration using an mdns address.

When I select the second one the connection string is:

Connection: socket://192.168.1.50:9100|HP Photosmart Premium C309g-m

This is a configuration using a fixed IP address.

I do not have nss_mdns installed.  All that's needed is the following in /etc/rc.conf:

avahi_daemon_enable="YES"
cupsd_enable="YES"
dbus_enable="YES"


In my opinion there are three things you did wrong:

1) You reported a solution ("add these dependencies") instead of a problem (what steps did you take and where did you get stuck?).
2) Whenever you get stuck you should ask for help on a mailing list or web forum.  If you don't get help you don't really lose time and if you do get help you gain time.  Asking for help is almost always a more efficient way of working.
3) Your message is overly dramatic, presumptuous, and condescending.  This is not a commercial shop where the customer is king and you get to say whatever you want.  This is a community where people are willing to help each other for free and as time permits.  In a community setting you need to behave differently.  You're lucky I typed out this whole message and didn't just close the bug.
Comment 2 Ronald F. Guilmette 2019-06-11 22:17:12 UTC
Sorry.  You ARE correct that cups-2.2.10 has a proper dependency already listed for avahi-app-0.7_2, and I apologize for missing that.

In my specific case however print jobs *did* in fact get into a hung state, while in the CUPS print queue, unless and until I also installed the nss_mdns package _and_ made the requsite adjustments to the hosts: line in my /etc/nsswitch.conf file.

The message produced by CUPS in the (pre nss_mdns install) failure case was "Unable to locate printer".  I discussed this in some detail on the avahi mailing list:

https://lists.freedesktop.org/archives/avahi/2019-June/002517.html

Apparently, a printer can have two different names, depending on how it is configured by its owner, and avahi, if left all to itself, can sometimes pick the Wrong One, which results in (a) a printer being known to CUPS but also (b) that same printer being "un-findable" when it comes time for CUPS to actually send a queued print job to the printer.

I found various suggestions online, suggesting that if one is using CUPS, then one should also install nss_mdns.  I did so, and then rebooted the entire system.  The minute the system came back up, my printer started printing the previously queued (but previously stalled) print job.

On this basis, I conclude that that there are certain real-life scenarios in which CUPS printing from a FreeBSD system may require the presence of nss_mdns.  I *do not* believe that the successes and failures that I have described above are due to the phases of the moon, or to any factors other than the presence/absence of nss_mdns, based on the available evidence.

On that basis it would seem prudent to me if a dependency upon nss_mdns were added to the cups-2.x.x. FreeBSD port/package.
Comment 3 Tijl Coosemans freebsd_committer 2019-06-12 10:26:58 UTC
Can you post the output of "lpinfo -v"?  I suspect Cups only uses Avahi for the dnssd:// protocol and that your printer may be using some other protocol where Cups uses libc for name resolution.
Comment 4 Ronald F. Guilmette 2019-06-12 18:29:53 UTC
This is the output of lpinfo -v:
================================================================
network https
network ipp
network ipps
network lpd
network socket
network http
network beh
direct hp
network dnssd://Brother%20MFC-7860DW._pdl-datastream._tcp.local/
network lpd://bromance/BINARY_P1
================================================================

I should perhaps note that regadless of all of the above, in the end, I ended up -manually- configuring -just- the URI in my /usr/local/etc/cups/printers.conf file, setting the URI to the following:

    lpd://192.168.1.57/queue

This works for me.  I can print.  And obviously, the above URI makes reliance on DNS or autodetection/autolocation of my printer entirely superfluous and unnecessary.  (Note that I have previously configured the printer to use the static address 192.168.1.57.)
Comment 5 Tijl Coosemans freebsd_committer 2019-06-13 21:18:44 UTC
Doesn't it work if you use dnssd://Brother%20MFC-7860DW._pdl-datastream._tcp.local/ as device URI?  For lpd://bromance/BINARY_P1 some DNS server or /etc/hosts file has to resolve "bromance".  That's not an mdns name.  You could check if your router handles both DHCP and DNS and if the printer tries to register its name in DNS when it obtains an IP over DHCP.  Then the computers on your LAN should use the router for DNS and they should be able to resolve bromance.  nss_mdns is only necessary I think if you try to use something like lpd://Brother%20MFC-7860DW.local/BINARY_P1.
Comment 6 Ronald F. Guilmette 2019-06-15 04:10:21 UTC
To answer your question, Yes, of course, I most certainly did try to use the printer as designated by the dnssd: URI, and that most certainly did not work.

I cannot comment on the remainder of your comment because most of it makes no clear sense to me at all, and thus, I am not even sure if I have understood either what you said or what you had intended to say.  (This is, I'm sure, more my fault than your's.)

I can say that I certainly have no plans to start relying on my SOHO router to provide DNS service for my local network.  It may in theory be capable of doing that, but I prefer run my own recursive resolver on one of my normal (and more powerful and more configurable) machines.
Comment 7 Tijl Coosemans freebsd_committer 2019-06-15 09:51:44 UTC
What is the output of "avahi-browse -r -t _pdl-datastream._tcp"?

My router runs both DHCP and DNS.  The DHCP server registers names reported by devices when they request an IP address in DNS.  So here "host <name of printer> <ip-of-router>" returns the IP address of the printer using regular DNS.  My printer also supports mDNS so it reports its IP address in response to mDNS broadcasts like "avahi-resolve-host-name <name of printer>.local".

If you want your computers to resolve "bromance" your DNS server needs to know about it, either by adding that name to the DNS server configuration or by letting your DHCP server register the name.  Or you could also add "bromance" to /etc/hosts on each computer.
Comment 8 Ronald F. Guilmette 2019-06-15 18:14:46 UTC
Output of the command you asked about is as follows:

+   nfe0 IPv4 Brother MFC-7860DW                            _pdl-datastream._tcp local
=   nfe0 IPv4 Brother MFC-7860DW                            _pdl-datastream._tcp local
   hostname = [BRN001BA9A2273F.local]
   address = [192.168.1.57]
   port = [9100]
   txt = ["TBCP=T" "Transparent=F" "Binary=T" "PaperCustom=T" "Duplex=F" "Copies=T" "Color=F" "usb_MDL=MFC-7860DW" "usb_MFG=Brother" "priority=25" "adminurl=http://BRN001BA9A2273F.local./" "product=(Brother MFC-7860DW)" "ty=Brother MFC-7860DW" "pdl=application/vnd.hp-PCL" "qtotal=1" "txtvers=1"]


In response to your other points, all I can say at this moment is that I'll have to think more about what you said.  I -think- I maybe understand, however:

*)  I have my printer set to a static IP, so it should NOT be doing DHCP with the router.  Nontheless, It's possible that the mini DNS server in my router may be becoming aware of the printer (and some name for it) anyway.

*)  As I may have already expressed, I am not in the least bit eager to be using the in-built DNS server in my router for anything at all.  I prefer to have routers just route, and to have name servers do name service.

*)  I understand the notion of putting "bromance" into /etc/hosts, however I am having some other issues/problems with /etc/hosts at the moment.  (In other contexts, edits I have made to that file do not seem to be having any effect.) Once I get those other problems sorted out, this may be -a- solution to the problem, however as I've noted, simply installing nss_mdns also seems to be a solution.
Comment 9 Tijl Coosemans freebsd_committer 2019-06-15 19:18:55 UTC
So the mDNS service name is "Brother MFC-7860DW" and the mDNS host name is "BRN001BA9A2273F.local".  On my printer I can only modify the mDNS service name.  The mDNS host name is always the DNS host name with .local appended.  Does your printer provide separate settings for these maybe?  I expected the mDNS host name to be "bromance.local".
Comment 10 Ronald F. Guilmette 2019-06-17 08:57:58 UTC
Created attachment 205169 [details]
current network configuration -- MFC-7860DW
Comment 11 Ronald F. Guilmette 2019-06-17 09:12:51 UTC
To answer that last question, yes, my printer had previously allowed me to set the "Node name" of the thing via the built-in control panel, and I (foolishly?) did that and set the "Node name" to "bromance".  This may perhaps have been the source of the problem(s) I reported.

Today I found that this machine has a web server running on port 80 that provides all sorts of control and configuration thingies.  I proceeded to use that to mess up this machine even worse than it already was, to the point where I could no longer even use it to print from either my Windows7 machine or my Ubuntu machine.  (Both of those had previously had no problems printing to this printer.)

Luckily, I found an option to do, a (factory?) "reset" on -just- the network related configuration bits on this device, so I did that and then, after that, I just set it back to using a static IP address again.  (I also gave it addresses for primary and secondary DNS servers, which I had never done before, although for the life of me I'm none too sure why a printer needs to do DNS lookups.)

Anwyay, the network config "reset" appears to have set the "Node name" back to its default value, as you can see in the attachment I've posted, and now the thing seems to be working just fine from Windows7 and also, now, from both Ubuntu/Linux *and* FreeBSD, when I "add" a CUPS printer using the dnssd: URI scheme. (I still have no idea what that scheme actually is, but I'm not going to argue with success.)

I'm going to leave this PR open for now, until someone tells me that nss_mdns is NOT needed, even when some given end-luser bozo, like me, foolishly decides to change the "Node name" on his/her printer.  (Believe me, I'll never try THAT again!)