You can troubleshoot this by separating mDNS resolution from service discovery.
If you can ping either name with .local appended, mDNS resolution is working. You should have the nss_mdns pkg installed and your /etc/nsswitch.conf should have a hosts line something like: hosts: files mdns dns Then ping bromance.local or BRN001BA9A2273F.local and see which one responds. Then you can search for the printer service once you can ping. From FreeBSD: avahi-browse _printer._tcp or avahi-browse _ipp._tcp depending on the printer you have. From a macOS machine: dns-sd -B _printer._tcp local or dns-sd -B _ipp._tcp local If you get a response here, you’re all set. If not, describe what works and what doesn’t. Tom > On Jun 7, 2019, at 10:29 PM, Ronald F. Guilmette <r...@tristatelogic.com> > wrote: > > > I've been trying, of late, to set up a fresh new FreeBSD system, and to > enable printing therefrom, and so far I've made just about every mistake > that it is possible to make. (The old saying is that software cannot > be made foolproof because they keep on inventing bigger fools. In this > case, that would be me.) > > Anyway, after much struggle I've managed to get CUPS and the cupsd daemon > up and running, and I've managed to add my specific local networked printer > (Brother MFC-7860DW) to CUPS so that it (CUPS) now knows that it exists as > a printer. I've also enabled both dbus and the avahi daemon to correctly > start up at boot time. > > Now I can print, e.g. from applications like firefox, HOWEVER, those print > jobs are consistantly failing to actually be sent to the printer, and CUPS > is consistantly showing me the following error when I go to look at these > (failed) print jobs via CPUS' in-built web interfacce (http://localhost:631): > > Unable to locate printer "bromance" > > I think that I may possibly have figured out the cause of the problem here, > or maybe not. I'm hoping that you folks will tell me if I have or not. > > Quite simply, several days ago, as I was starting this grand adventure, I saw > again something I had seen many times before which was that my networked > printer had an ugly and not very memorable sort of name name which was > showing up in the clients listing on my ASUS router. The name being shown > was always "BR" followed by some long string of numbers... not very memorable. > > So I took it upon myself to change the printer name, via the printer control > panel, to "bromance". This I apparently did successfully. Note in particular > the next-to-last line of this output from the bundled "snmp" program that > comes packaged with the CUPS 2.x.x package: > > https://pastebin.com/raw/1zp7GBui > > So anyway, bottom line, I do believe that CUPS knows my printer by the name > "bromance" and that it puts things/jobs into its spool along with instructions > that they should ultimately be sent to "bromance". > > While trying to debug my printing problem, I stumbled upon this helpful page > which gave me a hint as to how I could find the name that avahi is associating > with my printer's static IP address (192.168.1.57): > > https://bbs.archlinux.org/viewtopic.php?id=92011 > > I took the hint from that page and ran the following command, which produced > the output shown: > > % avahi-resolve-host-name -a 192.168.1.57 > 192.168.1.57 BRN001BA9A2273F.local > > From this I infer that avahi is... for reasons I am none too clear on... > still of the opinion that the correct and proper name for my local networked > printer is actually still "BRN001BA9A2273F". > > This, it seems to me, might possibly explain why CUPS is ready, willing, and > able to believe that my local priter is named "bromance" but when it (CUPS) > actually goes to try to actually send a job to that printer, it somehow > loses its mind and can no longer even find the bleepin' thing. > > What say you avahi folks? Is this a plausible explanation for my ongoing > inability to print? > > And why is avahi-daemon picking up the (old/original) name for this printer, > even after I have used the printer's control panel to change its name? And > where is it even getting this old name (BRN001BA9A2273F) from anyway?? That > name doesn't seem to be being provided as part of any SNMP data, so I am > totally in the dark about where and how avahi is even finding or obtaining > it. > > This is all most perplexing. > > I guess that I'll probably try and see if I can use the printer's control > panel to switch its name back to BRN001BA9A2273F, and then reboot everything > and try printing again, but if that doesn't work them I'm entirely screwed, > because I don't know what else to even try, and I don't have the first clue > of how to debug any of this any further. > > Any and all help will be appreciated. > > > Reards, > rfg > > > P.S. I have looked at my /usr/local/ect/avahi/hosts file and there is nothing > in there other than comments. > > P.P.S. I did try running some more test commands, just to ses if I could > maybe figure out what's going wrong here. Output for those is/was as follows: > > % avahi-resolve-host-name bromance > Failed to create host name resolver: Invalid host name > % avahi-resolve-host-name BRN001BA9A2273F.local > Failed to resolve host name 'BRN001BA9A2273F.local': Timeout reached > % avahi-resolve-host-name bromance.local > Failed to resolve host name 'bromance.local': Timeout reached > % avahi-resolve-host-name BRN001BA9A2273F > Failed to create host name resolver: Invalid host name > > _______________________________________________ > avahi mailing list > avahi@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/avahi _______________________________________________ avahi mailing list avahi@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/avahi
