> On Sep 17, 2018, at 5:08 AM, Marc Haber <mh+av...@zugschlus.de> wrote: > > Hi, > > I have my printer on a different subnet than the CUPS server, the > requests need to pass a router. CUPS server (parada) and router > (barrida) are both running Debian stable, with avahi 0.6.32. I'd rather > not upgrade to 0.7 unless I know positively that this will fix my issue. > My printer is a Lexmark C534 called c534-ka51. > > Regularly, but not reproducible, a record for c534-ka51.local seems to > remain stuck in the Avahi world. As a result, turning on the printer > will register "c534-ka51 (2)" visible on the CUPS server (parada) with > avahi-browse -a: > > + eth0 IPv4 c534-ka51 (2) Internet Printer local > + eth0 IPv4 c534-ka51 (2) UNIX Printer local > + eth0 IPv4 c534-ka51 (2) Web Site local > > Unfortunately, the CUPS erver wants to see c534-ka51._printer._tcp.local > which doesn't seem to be registered in avahi, not even on the router > (barrida). I'd paste avahi-browse --resolve --all output here, but it's > too long. It doesn't contain the string _printer though upon turning on > the printer. > > avahi-daemon --debug is unhelpful, no output at all on barrida when the > printer comes online. The debug output does only seem to mention changes > for local services. > > How do I debug this? How can I find out why > c534-ka51._printer._tcp.local does not show up? What blocks the printer > from registering as "c534-ka51" without the dreaded (2)? How can I > force-unregister a stuck "c534-ka51" without (2)? Why does restarting > avahi daemons on parada and barrida and the printer not resolve the > issue? > > Any hints will be appreciated. > > Greetings > Marc
I am a little confused about your topology and how it was ever working. So maybe a few questions will clear things up and then it will be easier to provide advice. .local is defined in RFC 6763 as link-local. From the RFC: "Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)” Therefore, by definition (and design), the service advertisements (and mDNS queries and responses) will not pass through a router to a different IP subnet. In order to make DNS service discovery cross a router, you can use unicast DNS queries and responses (sometimes called wide-area bonjour). CUPS will work fine across IP subnets using unicast DNS but in order to use service discovery, the PTR, SRV, and TXT records will have to be configured in the unicast DNS server that the client is using. There are several write-ups about how to do this correctly to make them discoverable to clients. I can look some up for you if you want. So maybe if you could provide IP addresses, prefix lengths, route information, domain name, and DNS resolver information about your printer, cups server, router, and client, it might be easier to track this down. The fact that you are seeing (2) appended to your service name is an indication that maybe a loop has formed and the host advertising the service has seen that service name coming from another device (possibly the router?) and so it increments a suffix to create a unique name. This makes me think that maybe the router is translating services between subnets as a feature. The software doing this on the router might be at fault. Or there may be a bridge loop you’re not aware of. This also happens sometimes when a client or server has multiple interfaces (wired ethernet & wireless) on the same subnet and the software gets confused seeing the advertisements coming in on a different interface. Thanks, Tom _______________________________________________ avahi mailing list avahi@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/avahi
