Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

USB URI: sometimes contains double manufacturing name

Aperta
  • Qualcosa non va?
#1,727 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C
Stelle
1.8k
Fork
352
Merge medio
2g 5h
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenPrinting/cups

Tutte le issue di OpenPrinting/cups

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.