[cups-devel] Hacking USB uris to make them more predictable

[Justin Carlson]

So, to summarize, in the case where someone plugs in multiple identical USB
printers that don't provide distinct serial numbers, our only recourse for
having multiple CUPS destinations to reliably target those printers is to
add information to the URI that distinguishes the devices based on
information that *might*, if we're lucky, remain stable across reboots, but
probably not across USB topology changes.  And since the mapping is
fragile, we have a choice, when we don't have an exact match, of falling
back to a fuzzy match (in which case we may target the *wrong* printer) or
not-matching (in which case we break a previously configured printer).

Sound about right?  I appreciate the input here to help my understand the
landscape.  Isn't interfacing with hardware *fun*?   :)

Do you have any sense for whether 'serial-number-is-bogus' is reliably
detectable across manufacturers?  Like, people leave it a zero-length
field, or set to all zeros, or similar?  No device manufacturer would do
something like set the same non-zero serial number for all devices, would
they?  Would They?

I have a sinking feeling I know the answer to this one already.  :)

-J


On Wed, Feb 22, 2017 at 12:56 PM Michael Sweet <msweet at apple.com> wrote:

> Justin,
>
> The issue is that a significant portion of the USB printers do not report
> a serial number (or rather, they report the same serial number for all
> printers...) so unless you can guarantee a single printer of a given
> make/model you are screwed.
>
> Traditionally we have added an interface identifier to the device URI when
> we can't get the serial number; that works as long as you don't move the
> printers to a different port and don't use a USB hub (which introduces a
> level of randomness...)
>
>
> > On Feb 22, 2017, at 2:39 PM, Justin Carlson <foozle at gmail.com> wrote:
> >
> > So I'm working with cups to handle USB printing in a managed system, and,
> > for reasons that probably aren't particularly interesting to this list,
> I'd
> > like to be able to directly query a USB printer and reliably determine
> the
> > URI that cups is going to use to refer to that device, preferably without
> > having to call out to any CUPS binaries/libraries.
> >
> > Having dug through the code a bit, the number of hacks/workarounds/fuzzy
> > matching stuff that is currently done during URI generation to cope with
> > weirdness and inconsistencies in the ieee1284 fields makes me deeply
> > uncomfortable -- it seems like matching those special cases and munges
> > would end up extremely fragile.
> >
> > However, URI generation for USB devices seems to be extremely well
> > localized -- AFAICT it's just in make_device_uri() in
> backend/usb-libusb.c.
> >
> >
> > So I'm thinking, at least for our system, of patching CUPS to use a
> > completely different USB URI scheme that ignores the ieee1284 fields
> > altogether in favor of using things in the USB device descriptor --
> > probably something like usb://{vendor_id}/{product_id}?serial={serial}.
> >
> > These URIs are not really user-visible in my use case, so I'm just
> > concerned about having a reliable reference to a given printer.
> >
> > Is this a terrible idea for some reason that I'm not seeing?  Are there
> > subtle dependencies on the existing URI scheme of which I may not be
> > aware?  Happy to get any feedback at all on this.
> >
> > Thanks,
> > -J
> > _______________________________________________
> > cups-devel mailing list
> > cups-devel at cups.org
> > https://lists.cups.org/mailman/listinfo/cups-devel
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
> _______________________________________________
> cups-devel mailing list
> cups-devel at cups.org
> https://lists.cups.org/mailman/listinfo/cups-devel
>