Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

USB URI: sometimes contains double manufacturing name

Open
  • Is something wrong?
#1,727 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
backend

Research direction

Read REPORTING_ISSUES.md, then inspect make_device_uri in backend/usb-libusb.c around the referenced v2.4.3 code. Reproduce the issue by rebooting the USB-connected printer several times on macOS and compare the generated URIs with the reported MFG, MDL, and DESC values; done means the printer consistently maps to the expected URI without the duplicated DYMO name.

Written by the indexing model from the issue text.

Description

investigating platform issue printer specific issue

Before you write the report
Read the REPORTING_ISSUES.md file in the main repository and prepare data mentioned there which looks relevant to you issue.

Describe the bug
We are developing a printer with ipp support over USB, but it also still supports a legacy interface (7/1/2) apart from the 2 ipp-usb interfaces (7/1/4).
It was reported that sometimes the printer shows up as 3 instances, whereas we expect 2 (legacy + ipp):

device for DYMO_LabelWriter_XYZ: usb://DYMO/LabelWriter%20XYZ?serial=00062098767890
device for DYMO_LabelWriter_XYZ_2: ippusb://DYMO%20LW%20XYZ%20Airprint%20(9876789)._ipp._tcp.local./?uuid=ebf898ff-4e8e-3a7d-4576-70d8233fbf52
device for DYMO_LabelWriter_XYZ_3: usb://DYMO/DYMO%20LabelWriter%20XYZ?serial=00062098767890

The weird case is the last one where there's a double DYMO field in the URI. It seems that the "model" part was not corrected by removing "DYMO"
Based on the code in https://github.com/OpenPrinting/cups/blob/v2.4.3/backend/usb-libusb.c#L1380, I don't see how this could even happen since if the MFG equals the start of MDL, it should be stripped.

Side note: we are using a dirty trick for certain reasons that I don't want to go into here: we're resetting the USB interface 2 seconds after it became connected.

My first thought was that the ieee fields could not all be read at some point in time, due to this reset. Function make_device_uri has backup behavior to use DESC field if MDL and/or MFG are missing. And indeed, DESC contains "DYMO LabelWriter XYZ", which is exactly the "model" part in the URI. But again, as far as I can understand, even if this happens, the "DYMO" part should be removed from the model according to the referenced code.

MFG:DYMO;CID:DYMOLabelWriter_XYZ;CMD: ;MDL:LabelWriter XYZ;CLASS:PRINTER;DESCRIPTION:DYMO LabelWriter XYZ;

Also, iProduct = DYMO LabelWriter XYZ, but I don't think it's relevant here (but I understood this is used for the displayed IPP-USB printer name)
iVendor = 0x0922

To Reproduce
Reboot the printer several times with USB connected to macOS

Expected behavior
The printer should always be mapped onto the same URI

System Information:

  • macOS 26
  • CUPS version 2.4.3

Additional context

Dominant language
C
Stars
1.8k
Forks
349
Avg merge
3d 4h
Merged PRs (30d)
14

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenPrinting/cups

All issues in OpenPrinting/cups

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.