[Shubham-Padkonde]

Known interoperability failure; please do not merge yet. The Xerox-B235 USB/IP simulator leaves the legacy entry visible while ipp-usb is active: the actual service name encodes bus/port (0101), while this patch matches bus/device address (0103). Current ipp-usb source also uses the port number. The identifier contract is under discussion with maintainers; the earlier controlled fixtures did not catch this mismatch. No fallback has been added.

USB discovery can open a legacy interface on a printer already handled by ipp-usb, even when its IPP-USB interface appears later in the descriptors. This change browses local _ipp-usb._tcp services once before enumeration, matches their hexadecimal bus/device addresses, and skips a matching printer only when a printer-class protocol-4 interface is present. Existing-queue printing bypasses the browse and filter.

The snapshot tracks service withdrawals, accepts either hexadecimal case, and falls back to legacy discovery on lookup failure. The discovery wait is bounded to one second for the whole scan.

Validation:

• Full build completed (make -j4).

• make -C backend test: 22 regression cases pass; six matching-service cases fail against the unmodified base. These regressions also run first in the top-level make test target.

• The same 22 cases pass with AddressSanitizer and UndefinedBehaviorSanitizer, including leak detection.

• Four integration checks pass using real CUPS DNS-SD/Avahi on an isolated local D-Bus with simulated USB descriptors: no advertisement, matching local advertisement, unchanged printing path, and service withdrawal.

• The real USB backend also exits successfully with the DNS-SD daemon unavailable.

• Hosted Linux CI passes all 22 USB regressions with both OpenSSL and GnuTLS.

• The macOS build and full test job, Windows build, and CodeQL analysis pass on commit 164075d.

The full local make test run stops in the unchanged JSON test when fetching Google's OpenID configuration (Credentials do not validate against CA certificates.). The same failure occurs in both Linux jobs on the unmodified upstream base, f57c6d9. The USB tests run before those network-dependent library tests, so their results remain visible in CI. No certificate checks are bypassed.

Physical IPP-USB printer validation is incomplete. On October 28, Till Kamppeter reported testing this branch with a Brother MFC-L8390CDW: the legacy USB entry was absent with ipp-usb running and reappeared when it was stopped. However, his log still reaches Failed to detach "usblp" rather than this patch's Skipping USB device ... served by ipp-usb message. That observation does not yet verify that the new early filter ran. I have requested the exact revision and _ipp-usb._tcp advertisement output in the OpenPrinting discussion. Existing-queue printing remains untested on physical hardware; the earlier automated USB checks use simulated descriptors. I do not currently have that hardware.

This implements the discovery-only scope assigned by @michaelrsweet in #186. Fixes #186.

[Shubham-Padkonde]

The go-mfp simulator recommended by Alexander exposed an interoperability failure in this patch. Please do not merge it until the identifier contract is resolved.

Reproduction: built OpenPrinting/go-mfp at 1bb71232c9e64854bb926866ebee7721b7c7bc9e, ran its modeling/examples/Xerox-B235.py model in USB/IP mode, attached it through the WSL kernel's vhci_hcd driver, and ran Ubuntu's ipp-usb 0.9.20-1ubuntu0.22.04.2 with a private local D-Bus/Avahi instance. The CUPS backend is the current PR build at 164075d.

Observed:

lsusb:                 Bus 001 Device 003: ID 0924:9d3b Xerox
_ipp-usb._tcp instance: 0101
legacy USB discovery:  still lists the Xerox while ipp-usb is active

The backend matches libusb_get_device_address() and therefore looks for 0103. In contrast, current ipp-usb device.go formats desc.Bus and info.PortNum; PortNum comes from libusb_get_port_number(). My implementation followed the bus/device-address example in ipp-usb #28, which differs from the producer now.

@michaelrsweet, should the backend follow the existing bus/port service, or should the advertisement use the bus/device address? I have raised the same concrete finding with Alexander in the ongoing OpenPrinting discussion. A blind bus/port fallback could match an unrelated printer behind another hub, so I have not added that fallback.

The earlier unit/DNS-SD fixture checks pass but did not establish compatibility with the actual ipp-usb identifier. This new run uses an emulated USB device, not physical hardware. Existing-queue printing remains untested. The attached emulated device was detached and all test daemons were stopped.

[michaelrsweet]

@Shubham-Padkonde Both ipp-usb and the usb backend should be using bus+device to identify a device.

If two printers are connected to a hub, the current ipp-usb usage of bus+port will fail because both printers will show up under the same bus and port number that the hub is connected to.

[Shubham-Padkonde]

Thanks, Michael. I'll keep the backend's bus + device-address match while we resolve compatibility with ipp-usb.

Alexander has since confirmed in the OpenPrinting discussion that bus + port is intentional in the current producer. The man page documents that format, and device.go implements it. That leaves a contract disagreement to resolve before this filter can work with released ipp-usb.

He also raised a separate requirement: planned system-config-printer mode switching would use CUPS USB URIs, so hiding those devices could remove the information it needs; the hp backend would also need consistent behavior.

@alexpevzner, could we settle both the identifier and the intended discovery behavior here with Michael before I revise this patch? I'll keep the do-not-merge notice in place. No further filtering changes or ipp-usb implementation have been made.