Симптом (бумага протягивается, страницы пустые) обычно означает, что МФУ не понимает формат растра или параметры носителя/дуплекса, которые генерирует 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 впишите сюда.