Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advertising services on the local machine #125

Closed
lathiat opened this issue May 20, 2017 · 39 comments
Closed

Advertising services on the local machine #125

lathiat opened this issue May 20, 2017 · 39 comments
Assignees
Milestone

Comments

@lathiat
Copy link
Owner

@lathiat lathiat commented May 20, 2017

It is desirable to support advertising services but only to the local machine, and not to advertise them to the network.

The specific use case is the IPPUSBXD project (https://github.com/tillkamppeter/ippusbxd/)

Currently we disable the loopback interface unless no other interfaces are activated. We should consider just enabling it at all times - there also seems to be a problem with the lo.IPv6 interface at least in avahi-discover it does not appear which is surprising.

Review the usage of loopback and figure out how to handle this nicely. One drawback to always advertising it is that local services will always appear 'twice' from 2 interfaces even on single interface machines. We could potentially not advertise services on loopback unless specifically requested, or not worry about it since we need to improve duplicate names on multiple interfaces anyway since we enabled IPv6 by default.

@lathiat lathiat added this to the v0.6.33 milestone May 20, 2017
@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented May 20, 2017

Duplicate appearing of services I have already without "lo" support. My laptop runs the Virtual Machine Manager (libvirt-based) and this creates a bridge network interface ("virbr") to provide network for the VMs by a kind of virtual NAT router. This makes all local CUPS queues (and other services from my laptop) already appearing under two interfaces. The same happens if you connect wired and wireless network simultaneously.
So for me it looks common having a service appearing in avahi-discover more than once. So I assume that clients must be able to handle it.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented May 20, 2017

Attaching the patch which makes entries on the "lo" interface being advertised, as suggested in the documentation of ippusbxd. Note that more work on Avahi is needed.

list-lo-entries.diff.txt

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented May 21, 2017

My problem is that if I apply my patch, the IPP-over-USB printer gets advertised (on the "lo" interface) and one can see it in the output of avahi-discover. The record shows its address with the correct IP, 127.0.0.1, but not with the hostname "localhost". Instead, the network host name of my laptop is shown, something like "XXX.local". So CUPS or cups-browsed (when not configured to use only IP addresses and no host names) try to access the printer via the URI "ipp://XXX.local:60000/ipp/print" (Note that ippusbxd uses port 60000 here as the standard IPP port 631 is already occupied by CUPS) and fail, as XXX.local is resolved to the laptop's network IP address and not to 127.0.0.1. Configuring cups-browsed to use only IP addresses makes it successfully using the URI "ipp://127.0.0.1:60000/ipp/print".
This needs to get solved in Avahi, as especially CUPS wants to be as standard-conforming as possible and not make exceptions for services on localhost. In addition, I also want to stop using the IP-address workaround with cups-browsed.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented May 21, 2017

By the way, when applying my patch, avahi-discover shows only the "lo"-interface entries for IPv4 and not for IPv6. ippusbxd supports both IPv4 and IPv6 and CUPS and cups-browsed, too.

@lathiat lathiat removed this from the v0.7 milestone Jul 13, 2017
@lathiat lathiat added this to the v0.8 milestone Jul 13, 2017
@lathiat lathiat added this to the v0.8 milestone Jul 13, 2017
@lathiat lathiat removed this from the v0.7 milestone Jul 13, 2017
@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 6, 2017

@rithvikp1998 has found a solution for the problem described here by adding a single-line change to my patch. With this, services from "lo" get advertised with "localhost" as server host name. This way said IPP-over-USB printers get correctly set up by CUPS and cups-browsed.
Patch attached:
local-only-services-support.patch.txt

tillkamppeter added a commit to tillkamppeter/avahi that referenced this issue Dec 15, 2017
…chine only

This is the patch attached to Issue lathiat#125 (on Dec 6, 2017) and also
shown in the readme.md of ippusbxd
(https://github.com/OpenPrinting/ippusbxd).

It makes also services on the loopback ("lo") interface being
advertised and these records use "localhost" instead of the network
host name of the machine as server host name. This way clients, like
for example CUPS or cups-browsed will find these local services and be
able to work with them as they were network services.
@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 15, 2017

Created pull request #161 applying my current patch.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 13, 2018

@lathiat, we urgently need this patch being adopted upstream in Avahi to implement standard-conforming printing. It is not only needed for IPP-over-USB using ippusbxd (https://github.com/OpenPrinting/ippusbxd) but also for the future format of printer and scanner drivers, the Printer Applications, which are daemons emulating a driverless IPP printer (and/or scanner) on localhost and communicate with the printer hardware. These applications will also advertise themselves via DNS-SD and, like ippusbxd, they have to do it local-machine-only on localhost, which is supported by Avahi if this patch is applied.
In Ubuntu we carry the patch as a distro patch for more than a year now and we did not get any complaints about it, neither bug reports nor security advisories.
Debian is not adopting the patch with the reasoning that it is not upstream in Avahi (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909564), so standard-conforming printing is not possible with Debian currently.
See also following slides in OpenPrinting Summit/PWG Meeting presentations:

@msekletar
Copy link
Contributor

@msekletar msekletar commented Feb 14, 2019

@tillkamppeter I'd be happy to pull down the patch to Fedora too if upstream doesn't move forward on this.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Feb 14, 2019

@msekletar, please go ahead using it as a distro patch for now to make also Fedora/Red Hat supporting the current IPP printing standards and to get a larger user base for the patch.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Feb 25, 2019

@lathiat, you promised to apply this (pull request #161) in Malta. Could you soon do it? Thanks.

@lathiat
Copy link
Owner Author

@lathiat lathiat commented Mar 28, 2019

The blocker for me to accept this patch, is that I don't think it is acceptable to hack the hostname of services on loopback to be "localhost". I am potentially fine with the half of the patch that enables the loopback interface. On Mac OS X, though, they don't enable the loopback interface unless all other interfaces are down. And that's nicer behaviour because it means that local services don't appear twice on two interfaces on systems with a basic single interface configuration.

My problem is that if I apply my patch, the IPP-over-USB printer gets advertised (on the "lo" interface) and one can see it in the output of avahi-discover. The record shows its address with the correct IP, 127.0.0.1, but not with the hostname "localhost". Instead, the network host name of my laptop is shown, something like "XXX.local". So CUPS or cups-browsed (when not configured to use only IP addresses and no host names) try to access the printer via the URI "ipp://XXX.local:60000/ipp/print" (Note that ippusbxd uses port 60000 here as the standard IPP port 631 is already occupied by CUPS) and fail, as XXX.local is resolved to the laptop's network IP address and not to 127.0.0.1. Configuring cups-browsed to use only IP addresses makes it successfully using the URI "ipp://127.0.0.1:60000/ipp/print".
This needs to get solved in Avahi, as especially CUPS wants to be as standard-conforming as possible and not make exceptions for services on localhost. In addition, I also want to stop using the IP-address workaround with cups-browsed.

In the same way that CUPS does not necessarily want to make exceptions for localhost only services in order to be standards conforming, we have the same problem in Avahi. You want to add the same localhost-exception to avahi that you don't want to add to CUPS. So hopefully you can understand from that point of view why from the outset it doesn't seem right.

Given that you are implementing this IPP behaviour which is using localhost (and one of the few cases where mDNS services are used from localhost) I would argue it makes more sense to put such logic in CUPS, if it was to be put anywhere.

The entire call path within avahi for browsing service types and resolving a specific service returns the interface index ('scope') for that specific service. If a service exists on multiple interfaces, when you resolve it, you get multiple callbacks for each interface with the interface ID. And then when you query for the IP address for the hostname, whether through the avahi resolver or the glibc gethostbyname interface - you should send that same scope ID to ensure you get the IP of the relevant interface. This is actually important for link-local IPv6 services, if you don't set that scope ID, you won't be able connect.

Technically, these are actually unique services, because Avahi/mDNS has no way of knowing if "Brother Printer" on 1 interface is the same "Brother Printer" as on another interface. It's possible to be on 2 distinct networks, with two devices with the same name. In reality that doesn't happen most of the time, but it is possible. Ideally a selection UI for services would let users select between interfaces and technically any UI that allows users to select a service, should let the user choose between the two interfaces. It should then keep and re-use that scope ID for future queries, which will ensure it gets an IP that is actually listening on that port.

Hence, ideally, cups should be remembering the interface scope and using that to query the IP. Of course, for normal network printers and the majority of network scenarios where the same service name doesn't exists on 2 separate networks that is actually 2 different devices, that may not be totally desirable since if you moved for example from wired to wireless, you might want to find the printer on either interface. So if you just used the hostname, that would work. Though arguably, you should/could have instead not re-used the "same" printer for both interfaces, but setup 2 different printers for each interface. On MacOSX you can actually encode the interface name/index in the hostname/URL, e.g. brother-printer.local%lo - unfortunately that does not currently work on Linux when passed direct to gethostbyname() - though that is something I have wanted to fix.

Another alternative would be to have cups enumerate all of the IP addresses for a host and try to connect to all of this. This also is something I would normally expect CUPS to do, particularly for example to correctly handle IPv4+IPv6 when perhaps that host only has connectivity to one of them.

The last alternative I can think of is that IPPUSBXD could not bind to localhost but instead bind to all interfaces but filter the connections to only accept connections from the local host.

I'll setup a reproducer with CUPS to observe it's behaviour with regards to name resolution, trying multiple IPs, etc.. and see if I can come up with a more concerete suggestion on fixing this from the CUPS side.

@lathiat
Copy link
Owner Author

@lathiat lathiat commented Mar 28, 2019

To bring some clarity to the general situation, a device being on localhost is not the only place situations like this occur.

If a device has multiple IP addresses and a given service only listens on one of them, you also have this same kind of problem. That can be two IP addresses in different subnets but on the same network/interface, it can be having both an IPv4 and IPv6 address, or it could be that both the advertising and browsing device are both on two separate networks (but the service only listens on one of them). In all of these cases unless you use the extra information that Avahi gives you during service browse time (e.g. to then specify the interface and protocol to resolve the address on), you will get back multiple IPs and you need to try them all in order to find one that works.

So really the most straight forward solution would be to ensure that CUPS enumerates the hostname for multiple IP addresses and tries all of them. That is easily done even with the glibc resolving API directly looking up the hostname.local. That's part of what I'll check into with CUPS.

@lathiat
Copy link
Owner Author

@lathiat lathiat commented Apr 4, 2019

I found this old bug which illustrates my point perfecty:
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1099184
apple/cups#4305

The complaint is that when CUPS discovers a printer, it sometimes resolves the IPv6 address of the hostname - but the printer does not respond on IPv6 so the print fails.

This is why CUPS should be keeping track of the scope ID and address family firstly, or worst case, why it should fall back and try all of the IP addresses. As mentioned by the person that closed the bug - though - that person failed to understand that Avahi does provide this information, CUPS is currently not using it.

We can solve both that problem, and this one, with the same fix.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Apr 4, 2019

Trent, could you check whether cups-browsed does it right?

The resolve_callback() function in utils/cups-browsed.c of cups-filters contains the readout of interface name, host name, IP address, and address family from the Avahi message when a new printer appears. It actually works with ippusbxd also when the initial Avahi patch (without renaming the host name to "localhost"), IPv6 also works, but mentioned Launchpad bug not tested.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Apr 18, 2019

Trent, could you create a new Issue on CUPS upstream describing which changes are needed on CUPS in order to handle DNS-SD messages from services on the local machine (via "lo" interface) correctly? Thanks.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Jul 31, 2019

Concerning ippusbxd to not use "lo" but all the other interfaces instead, this would be really awkward as ippusbxd had to watch all the interfaces appearing and disappearing and to bing itself all the time to the available interfaces. Such an awkward technique I do not want to make the standard for ippusbxd and all IPP Printer/Scanner Applications.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Jul 31, 2019

Trent, now it is already August and I am still waiting for your checks on CUPS you have promised and also the resulting Issue report on CUPS upstream.
I have also done some changes on cups-browsed, to solve OpenPrinting/cups-filters#136. After that Avahi would still work with the first part of my patch, as it does the "localhost" exception handling by itself, as before. Could you have a look whether it is still doing the right thing? Thanks.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Aug 2, 2019

It is theoretically possible that ippusbxd would advertise its service on all interfaces (AVAHI_IF_UNSPEC) and listen to all of them (Bind to IP address 0.0.0.0:port) and then filter the inquiries to accept only the ones from the local machine.
In practice this would cause several problems:

  • The USB printer is advertised in all networks the host machine is connected to (Ethernet, Wi-Fi, local VMs, VPN, ...), so everyone knows that there is a USB printer on employee XXX's desk. Usually USB printers are not visible through networks, so we have a privacy problem.
  • The network is polluted with printer advertisements (which make it automatically into print dialogs) for a printer which is not actually usable, as the clients do not know from the DNS-SD records that this printer filters non-local inquiries. There should never be DNS-SD service advertisements which do not represent an actually working service.
  • Not letting an inquiry to a local service go through the loopback interface ("lo", "localhost") would take up additional network resources and could perhaps make the transaction visible to the outside or even the data being routed to the outside and back to the local machine, causing security/privacy risks.

Therefore the current architecture of ippusbxd represents best what one expects from a USB printer. The IPP-over-USB is not intended for automatic printer sharing but for driverless USB printing (CUPS sets up the printer automatically querying all needed information from the printer) and for configuring the printer hardware from the client through its web admin interface.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Aug 2, 2019

For me it looks more consistent if the DNS-SD record produced by Avahi for the loopback ("lo") interface reports "localhost" as host name and not the host's network host name. You say in your first comment from March 28 you tell that a service which exists on multiple interfaces is reported independently for each interface and each of these DNS-SD reports are absolutely independent, it is even possible that different services can have the same service name and report on different interfaces.
So to make each report (set of service name, domain, service type, host name, interface, IP, and port) in itself consistent especially the set of host name, interface, and IP should match. This is not the case if here a machine's network host name with the "lo" interface and the 127.0.0.1 IP is reported.
You can see it running the following commands:

till@till-x1yoga:~$ host till-x1yoga.local
till-x1yoga.local has address 10.0.0.112
till-x1yoga.local has address 10.0.0.108
till-x1yoga.local has address 192.168.122.1
till-x1yoga.local has address 10.249.158.1
till-x1yoga.local has IPv6 address fe80::530d:50bb:a232:568b
till-x1yoga.local has IPv6 address fe80::e4e7:63c4:4c0c:111e
till-x1yoga.local has IPv6 address fe80::cc2c:91ff:fe9f:48f8
till-x1yoga.local has IPv6 address fe80::fc45:42ff:feee:741f
till-x1yoga.local has IPv6 address fe80::fc54:ff:fee2:dbd6
till@till-x1yoga:~$ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1
till@till-x1yoga:~$

gethostbyname only finds the non-loopback IP addresses when querying the network host name and not the loopback IPs 127.0.0.1 and ::1 whereas querying "localhost" only finds the 127.0.0.1 and ::1 IPs, so "till-x1yoga.local", "lo", and 127.0.0,1 / ::1 are not belonging together but "till-x1yoga.local" is the correct host name for any other interface's DNS-SD report.
As any client (not only CUPS) had to replace the network host name by "localhost" for a service reported on the "lo" interface it makes more sense if the DNS-SD infrastructure (Avahi) already does this replacement.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Aug 2, 2019

If a printer (device) advertises itself via DNS-SD on both IPv4 and IPv6 but only listens on IPv4 or generally advertises itself on network interface/network protocol/service type combos on which it is not listening this is a bug in the printer's (device's) firmware. In Avahi one cannot do much about it as Avahi is not checking each DNS-SD record for its validity (is communication accepted this way?). CUPS (or any other client) can only overcome such bugs by trying through the advertised combos until finding a working one, as already said here.
An improvement would be prioritization, for example trying IPv4 first or for the interfaces trying "lo" first, then Ethernet, then Wi-Fi, ...

@michaelrsweet
Copy link

@michaelrsweet michaelrsweet commented Aug 7, 2019

If Avahi returns 127.0.0.1 as one of the addresses for a .local lookup, that will cause some serious security problems when machine A (a.local.) looks up machine B ("b.local.") and gets its own loopback address. By returning localhost ("localhost.") that security issue is avoided.

Keep in mind as well that when CUPS tries to connect to a printer/server, it tries all of the addresses returned by a lookup in parallel until one of the connections succeeds. Since CUPS also validates the Host: header in requests (and block any attempt to communicate with cupsd over the loopback interface if the hostname is not "localhost" or "localhost."), this will result in a successful connection but a failed request, breaking printing.

So you really do need to return "localhost" for services registered on the loopback interface.

@pohhyli
Copy link

@pohhyli pohhyli commented Aug 7, 2019

@lathiat
Copy link
Owner Author

@lathiat lathiat commented Dec 6, 2019

New findings -- I purchased a Deskjet 3700 which has IPP everywhere and did some further experimentation.

For whatever reason when CUPS discovers an _ipp._tcp printer via mDNS (regardless of if it's IPPUSBXD based or not), it generates an ipp:// URL having resolved the hostname, e.g. ipp://optane.local:60000/ipp/print|HP DeskJet 3700 series

This then means that when it later connects, it has lost the information about which interface index to resolve the hostname over. It tries to connect to one of the public IPs (or really, some IP at random) and fails. It would be possible in theory to add the interface index as optane.local%lo but there is so much manual URL handling I think this would be difficult and linux nss-mdns doesn't currently support this (though I plan to add it).

However if you instead use a dnssd:// URL which CUPS already supports, then it will actually do the lookup using mDNS/Avahi at the time of printing already, and then correctly resolves the hostname using the interface index and prints successfully (tested with a real setup) without the localhost hack patch:
The CUPS URL to use is something lke: dnssd://DeskJet%203700%20series%20%5BCN96G6D0PR06GY%5D._ipp._tcp.local/

If you have another kind of mDNS service such as _pdl-datastream._tcp CUPS already uses a URL in this form (e.g. when doing "add new printer"). But for whatever reason if it's an _ipp._tcp service it overrides to the ipp://hostname form instead.

So I need to understand why CUPS is generating an ipp:// URL instead of a dnssd:// URL and if this is intentional for some reason - or otherwise I suspect it's probably an oversight but it would be great to know if there is some actual intentional reason for this from @michaelrsweet and @tillkamppeter as really this behaviour doesn't make sense to me - in all cases I think we should be doing the reference via dnssd and then letting CUPS make the IPP connection from there.

I tried to trace what area of the CUPS code is doing this and failed - I couldn't logically follow it and then I tried tracing in gdb to understand the call flow and failed there I think largely because I could not figure out how to get gdb to reliably attach to the cups-deviced process that is forked from cupsd dynamically and that seems (at least I think) to be the one calling the functions that generate the URLs.. does anyone have a recipe for this? I tried setting "set follow-fork-mode child" and "set detach-on-fork off" but it seemed to just follow some fork early on and then lose the parent cupsd process.

If we can make this work then all I need to do is merge the patch to actually allow publishing on the loopback interface which I am 100% happy to do - I am just not happy with monkeying the URL to localhost.

As a side note for this testing largely I disabled cups-browsed and used the built-in cups code for dnssd browsing which appears to do the same thing more or less - should this functionality should be deprecated from cups-browsed or is it somehow a superset of the built-in functionality? In any case the fix applies whichever discovery path you are using. I think cups-browsed is using cups to generate the ipp:// URL so if we changed that it would fix both cases.

So if I could get some input from here that'd be great otherwise perhaps we could open this as a bug over at CUPS now to discuss it?

  • Trent

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 6, 2019

@lathiat, I assume you are making pure CUPS observations, not running cups-browsed. Make sure you make all observations with cups-browsed NOT running for now.
I have a HP DeskJet 2540 which is a Wi-Fi and IPP-over-USB MF device.
After starting ippusbxd with only this printer connected via USB:

ippusbxd

I get

$ driverless
ipp://localhost:60000/ipp/print
$ lpstat -l -e
[...]
Deskjet_2540_series_BR54BFB02C05XK_ network none ipp://Deskjet%202540%20series%20%5BBR54BFB02C05XK%5D._ipp._tcp.local/
[...]

So the CUPS which I have installed (2.2.12-2ubuntu1 on Eoan/18.10) generates URIs with ipp: (or ipps:) and the DNS-SD service name, no resolved host name. Seems that the ipp CUPS backend resolves the host names/IPs/ports whenever they send off a job.
@lathiat which OS, CUPS, and cups-filters versions are you using? Are you using the Avahi which comes with the (Ubuntu) distro or your upstream GitHub snapshot Avahi?
@michaelrsweet, how does CUPS decide whether it uses DNS-SD-service-name-based URIs (as I observe) or hostname-based URIs (as @lathiat) observes? Is there a config option? Does it depend on the CUPS version?
In cups-browsed currently hostname-based URIs are used, but as I see here one should better use service-name-based URIs. I will change that soon. But let us get pure CUPS working first, correcting cups-browsed after that should not be a big issue.

@lathiat
Copy link
Owner Author

@lathiat lathiat commented Dec 6, 2019

I’m on Focal latest now, but I was getting the same hostname behaviour on Eoan. Curious that yours uses the dns-sd service name with ipp://. I was using ippusbxd from git when testing today though I’ll re-test with the Ubuntu version again when I’m at a machine next (which I had done before in the past) since it’s possible some flag it’s setting is changing what cups is doing. I’ll also share my cups config and a dump of what ippusbxd is doing.

Using Ubuntu avahi (from focal) except I rebuilt and changed the patch not to switch out the hostname.

And for what it’s worth when I was using cups-browsed with the implicitclass URL it sets up during printing it would get switched out for the same ipp://optane.local URL

Curious would be good to know what drives CUPS to choose between the two.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 6, 2019

The version of ippusbxd, whether GIT or the Ubuntu package, has probably no influence. The changes are small.
I also get a service-name-based URI for a Printer Application (emulated IPP printer) on the local machine.
My Avahi is the unchanged Ubuntu package as it comes with Eoan.
cups-browsed and the implicitclass backend always use host-name-based URIs, as cups-browsed is generating them this way. Make sure that cups-browsed is not running, as it makes temporary CUPS queues permanent and uses the implicitclass backend then.
We need input from @michaelrsweet to see how CUPS makes the URIs for their temporary queues.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 6, 2019

Here is my /etc/cups/cupsd.conf file:
cupsd.conf.txt

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 10, 2019

@lathiat, Michael Sweet is on an extended vacation, so we cannot wait for an answer from him.
But due to the fact that cups-filters uses host-name-based URIs (ipp(s)://<HOST NAME OR IP>:<PORT>/<RESOURCE>) and CUPS uses DNS-SD-service-name-based URIs (ipp(s)://<SERVICE NAME>.<REG TYPE>.<DOMAIN>/) I have investigated the viability of switching cups-filters over to DNS-SD-service-name-based URIs and this is rather easy as libcups has a function to resolve the DNS-SD-service-name-based URIs to host-name-based ones. So I am working on this right now and soon (in a few days) we will also have cups-filters use the DNS-SD-service-name-based URIs.
The reason for the difference is that CUPS used the host-name-based one formerly, when I started to create cups-browsed, and later on CUPS switched to the DNS-SD-service-name-based URIs and I did not follow in cups-filters.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 10, 2019

The driverless utility of cups-filters I have switched over to DNS-SD-service-name-based URIs now (commit in cups-filters). cups-browsed will follow soon.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 10, 2019

Also note that cups-browsed has a workaround for Avahi with the loopback device support but without the host name switch to "localhost", as the former is done by me several months earlier than the latter, done by one of my students. In the meantime I had made cups-browsed working only with the first part by switching the host name in the URIs by itself.

@michaelrsweet
Copy link

@michaelrsweet michaelrsweet commented Dec 11, 2019

@tillkamppeter Temporary queues use the resolved service name since the expectation is that the queue will go away. But queues created manually use the DNS-SD name.

(the dnssd scheme is an artifact of the original macOS implementation, but we support DNS-SD service names for ipp:/ipps: URIs as well...)

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 11, 2019

Also note that the IPP standard still defines the ipp://<HOST>:<PORT>/ipp/print URI and as non-CUPS apps could also access IPP printers the ipp://localhost:<PORT>/ipp/print URI should get intuitively deducted from the DNS-SD record of a local Printer Application or ippusbxd, independent of that CUPS and cups-filters are using DNS-SD-service-name-based URIs now.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 11, 2019

Big advantage of DNS-SD-service-name-based URIs is also that they are independent of the port, so that one does not need to take so much care that the Printer Applications take always the same port on each start.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 11, 2019

@michaelrsweet, when I have no cups-browsed running, ippusbxd running for a local IPP-over-USB printer, lpstat -l -e shows the temporary queue for the printer with DNS-SD-service-name-based URI:

Deskjet_2540_series_BR54BFB02C05XK_ network none ipp://Deskjet%202540%20series%20%5BBR54BFB02C05XK%5D._ipp._tcp.local/

CUPS version is 2.2.12 on Eoan.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 11, 2019

@michaelrsweet, does the resource of a DNS-SD-service-name-based URI has any meaning, or does one get to the same destination also without it?
So does

 dnssd://devel2-printer%20%40%20virt-devel2._ipp._tcp.local/cups

and

dnssd://devel2-printer%20%40%20virt-devel2._ipp._tcp.local/

mean the same?

@michaelrsweet
Copy link

@michaelrsweet michaelrsweet commented Dec 11, 2019

@tillkamppeter Yes, they are treated the same.

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 11, 2019

cups-browsed is also switched over to DNS-SD-service-name-based URIs now (commit in cups-filters).

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Dec 11, 2019

Thanks, @michaelrsweet, in cups-browsed I let the URIs of remote CUPS queues have a /cups resource, as your dnssd backend does, so one can easily recognize that they are pointing to remote CUPS queues. Now cups-filters should do the same as CUPS does in terms of device URI generation.

@lathiat
Copy link
Owner Author

@lathiat lathiat commented Dec 22, 2019

Note for later; the patch in it's current form (including as shipping on Ubuntu) causes messages like this:
sendmsg() to 0:0:ff02:: failed: Network is unreachable

This seems to happen becuase the AvahiInterface protocol is set to PF_LOCAL instead of PF_INET or PF_INET6 as we assume elsewhere. This causes some if/else statements not to run to send data including the mcast address.

(gdb) bt
#0 sendmsg_loop (fd=12, msg=0x7fffffffe190, flags=0) at socket.c:460
#1 0x00007ffff7f902a8 in avahi_send_dns_packet_ipv6 (fd=12, interface=1, p=0x5555555ad4c0,
src_address=0x55555558bd9c, dst_address=0x0, dst_port=0) at socket.c:624
#2 0x00007ffff7f814e8 in avahi_interface_send_packet_unicast (i=0x55555558bd60, p=0x5555555ad4c0, a=0x0, port=0)
at iface.c:601
#3 0x00007ffff7f8156a in avahi_interface_send_packet (i=0x55555558bd60, p=0x5555555ad4c0) at iface.c:608
#4 0x00007ffff7f9374f in append_known_answers_and_send (s=0x55555558c660, p=0x5555555ad4c0) at query-sched.c:269
#5 0x00007ffff7f938c4 in elapse_callback (e=0x5555555aa670, data=0x5555555aa620) at query-sched.c:310
#6 0x00007ffff7f7ee77 in expiration_event (timeout=0x55555558db00, userdata=0x555555588b00) at timeeventq.c:94
#7 0x00007ffff7fc34fa in timeout_callback (t=0x55555558db00) at simple-watch.c:447
#8 0x00007ffff7fc38e1 in avahi_simple_poll_dispatch (s=0x555555584ac0) at simple-watch.c:570
#9 0x00007ffff7fc3a4a in avahi_simple_poll_iterate (s=0x555555584ac0, timeout=-1) at simple-watch.c:605
#10 0x000055555555ef2f in run_server (c=0x55555557e200 ) at main.c:1256
#11 0x000055555555fc38 in main (argc=1, argv=0x7fffffffe528) at main.c:1674

Preparing to commit the patch to publish localhost service but just need to fix this issue first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants