On 5/25/21 10:22 AM, Tomasz Torcz wrote:
Dnia Mon, May 24, 2021 at 08:21:07PM -0400, Solomon Peachy napisał(a):
Well, if I want to configure the printer, I need to know what to point my browser at. But sure, if a dialog gives me a link, that is a way. Though it means yet another layer of indirection (bringing up the dialog first, only to get redirected to a web interface).
Running 'ippfind' will show you the list of all IPP-capable printers that are advertising themselves through mDNS, and the URI they can be reached at.
Nice command, but it returns host in the .local domain, resolving of which doesn't work half of the time. The host sharing the printer has normal, functioning FQDN, couldn't ippfind return it?
IMHO the proper thing to do would be to investigate why you experience the issues with .local instead of rewritting software which uses .local addresses.
Unless you have disabled weak dependencies in dnf, avahi and nss-mdns is installed together with CUPS, and .local resolution works fine with them. (The other issue is that 'driverless' binary sometimes fails to provide driverless ipp uri, which is a problem during searching for printers, but ippfind always finds the device just fine. I track it here [1])
I tried Avahi+resolved setup too and address resolving worked as well, but it needed more steps to make it work (enable mdns in resolved and enable mdns and llmr in NM for your network interface).
If the resolution still doesn't work after checking your setup, it would be great if you filed a bug against nss-mdns or resolved, based on which solution do you use.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1954469
I do control the network, including DNS server, but this zeroconf stuff is a jungle.
(some time ago I'v tried to share common LAN bookmarks using zeroconf, but only Epiphany supported it. Firefox never get there - bz 173804. Today, I don't even know what the equivalent of /etc/avahi/services/ is in the systemd-resolved world).