cups-2.4.19-alt1 cups-filters-2.0.1-alt2 libcupsfilters-2.2.1-alt3 Стенды: Alt Education 11.2 XFCE x86_64, обновленный до Sisyphus Проверялось на реальном оборудовании: Ноутбук F+ Flaptop FLTP-5i5-16512-W МФУ Canon i-SENSYS MF264dw II Шаги воспроизведения: 1. Открыть браузер -> http://localhost:631/ -> Администрирование -> Добавить принтер -> Выбрать Canon i-SENSYS MF264dw II с протоколом socket/lpd/dns-sd -> Выбрать вендора Canon -> Выбрать драйвер "Canon MF260 II Series, driverless, cups-filters" -> Завершить добавление 2. Перейти в Принтеры -> Выбрать принтер -> В выпадающем списке выбрать "Печать пробной страницы" Результат: МФУ начинает бесконечно забирать листы, будто печатает в режиме двусторонней печати (лист забирается из лотка подачи, выходит из выходного лотка, сразу же затягивается обратно и снова выходит из выходного лотка). Когда бумага в лотке подачи заканчиваются принтер сообщает, что бумаги нет, если снова добавить листы в лоток подачи, он продолжит их забирать. Печать как таковая при этом не осуществляется - листы остаются чистыми, ничего не распечатывается. Отмена задания проходит успешно, без зависаний и ошибок. Ожидаемый результат: распечатывается пробная страница.
Симптом (бумага протягивается, страницы пустые) обычно означает, что МФУ не понимает формат растра или параметры носителя/дуплекса, которые генерирует driverless PPD. Чтобы разобраться, нужна информация от самого МФУ и от CUPS: 1. Вывод ipptool -tv ipp://IP_МФУ/ipp/print get-printer-attributes.test (полный, лучше файлом). 2. Вывод driverless list и сгенерированный PPD: содержимое /etc/cups/ppd/<имя_принтера>.ppd, а также lpstat -v. 3. /var/log/cups/error_log с LogLevel debug2 в /etc/cups/cupsd.conf (после изменения systemctl restart cups), снятый при печати пробной страницы, до отмены задания. 4. Какой именно URI использовался при добавлении: socket://, lpd:// или ipp://? Судя по описанию, очередь driverless создавалась поверх socket/lpd. Проверьте, пожалуйста, добавление через ipp://IP_МФУ/ipp/print или через dnssd (в system-config-printer это тот же принтер с протоколом ipp/dnssd, либо lpadmin -p test -E -v ipp://IP_МФУ/ipp/print -m everywhere) и напишите, меняется ли поведение. 5. Есть ли на МФУ включённые настройки дуплекса/AirPrint в веб-интерфейсе и меняется ли что-то при печати с явными опциями: lp -d <очередь> -o sides=one-sided -o media=A4 /usr/share/cups/data/testprint.
Created attachment 22123 [details] logs Прилагаю запрошенные логи. 4. Использовался протокол socket://. Если добавить принтер по протоколам dnssd и ipps с тем же драйвером - печать пробной страницы успешная. 5. Двусторонняя печать есть Печать с явными опциями заканчивается аналогично, будто в режиме двусторонней печати, листы остаются пустые
Спасибо, картина ясна. Тот же PPD "driverless, cups-filters" через dnssd/ipps печатает, а через socket:// нет: этот PPD выдаёт Apple Raster (URF), который принтер принимает только по IPP, а на порт 9100 Canon ждёт UFRII/PCL и протягивает бумагу вхолостую. Поэтому sides=one-sided ничего не меняет: принтер вообще не разбирает поток. Собственно driverless-печать работает, поэтому переименовываю баг: проблема в том, что веб-интерфейс CUPS показывает driverless-PPD для socket/lpd-адресов. Для "IPP Everywhere" admin.cgi такую проверку делает (пункт показывается только для ipp/ipps/dnssd), а для PPD с ppd-name driverless:... из cups-filters нет. Оставляю открытым, исправление в admin.cgi готовлю у нас, в следующей сборке cups driverless-PPD для не-IPP адресов из списка исчезнут. Две просьбы. 1. Проверьте, печатает ли этот Canon вообще без добавления принтера: driverless для того и придуман. Очередь на implicitclass:// должен создать cups-browsed сам, посмотрите lpstat -v, и напечатайте на неё: lp -d <имя_очереди> /usr/share/cups/data/testprint. Если очереди нет, проверьте, что служба cups-browsed запущена (systemctl status cups-browsed). 2. Заведите, пожалуйста, issue в апстриме CUPS: https://github.com/OpenPrinting/cups/issues. По-английски, примерно так: Title: Web UI offers cups-filters "driverless" PPDs for socket:// and lpd:// queues The "Add Printer" page in the CUPS web interface hides the "IPP Everywhere" model when the device URI is not ipp://, ipps:// or dnssd://, but it still lists the "driverless" PPDs generated by cups-filters (ppd-name "driverless:ipps://..."). Such a PPD produces Apple Raster (image/urf) only, so a queue with a socket:// or lpd:// device URI created this way cannot print: a Canon i-SENSYS MF264dw II feeds blank pages endlessly, Pantum M6700DW / CM1100ADW hang with "Printing" on the panel. The same PPD used with a dnssd:// URI prints fine. Suggestion: in cgi-bin/admin.c hide ppd-name entries starting with "driverless" for non-IPP device URIs, the same way SHOW_IPP_EVERYWHERE is handled. CUPS 2.4.19, cups-filters 2.0.1. Ссылку на issue впишите сюда.
