beh сам ничего не печатает, он лишь запускает socket backend с указанным URI и следит за кодом возврата. Раз напрямую через socket:// то же МФУ печатает, нужно понять, чем отличается сессия под beh. Для этого пришлите, пожалуйста:

1. /var/log/cups/error_log с включённым отладочным уровнем: в /etc/cups/cupsd.conf поставить LogLevel debug2, перезапустить cupsd (systemctl restart cups), очистить очередь, отправить пробную страницу, дождаться зависания, отменить задание с ноутбука и приложить лог целиком.
2. Вывод lpstat -v и содержимое /etc/cups/ppd/<имя_принтера>.ppd для очереди с beh.
3. Какой драйвер/PPD выбирали при добавлении очереди с beh и такой ли же был в очереди с прямым socket://, которая печатала успешно.
4. Для сравнения тот же error_log при печати напрямую через socket://IP (без beh), чтобы сопоставить.
5. Что после зависания показывает cupsd в статусе задания: lpstat -o и lpstat -p -l.

Created attachment 22121 [details]
logs_beh

Собрала логи, которые вы просили. 
Сегодня даже в случае прямого подключения по wi-fi принтер зависает. Вчера точно работал. Однако error_log все же решила приложить для обоих случаев, возможно в них будет какая-то полезная информация.

Спасибо за логи, но, к сожалению, в них нет самого главного. Оба error_log содержат только последние ~50 секунд: момент отмены задания. Старт задания, запуск фильтров и бэкенда, обмен с принтером в них не попали. Причина: при LogLevel debug2 лог заполняет 1 МБ за несколько секунд, и cupsd по умолчанию (MaxLogSize 1m) ротирует его, старая часть уходит в error_log.O и затирается при следующей ротации.

Из того, что видно, важное: очередь Beh_CM1100ADW создана с PPD "Pantum CM1100ADW Series, driverless, cups-filters" (в PPD: *cupsFilter2: "image/urf image/urf 0 -"), а device-uri у неё socket://10.88.144.151. То есть на порт 9100 принтеру уходит Apple Raster (URF), формат, который предназначен для отправки через IPP (ipp://, ipps://, dnssd://). По socket принтер ожидает свой язык (PCL/PS), и URF-поток на порту 9100 как раз даёт симптом "Печать" без результата и зависание. beh здесь ни при чём: он просто запускает тот же socket-бэкенд. Ваше замечание, что сегодня и прямое socket-подключение перестало печатать, это подтверждает.

Прошу перепроверить в двух корректных конфигурациях:

1. Driverless по IPP без TLS и без dnssd, чтобы исключить проблемы с сертификатом принтера:
   lpadmin -p cm1100 -E -v ipp://10.88.144.151/ipp/print -m everywhere
   lp -d cm1100 /usr/share/cups/data/testprint
   Если нужен именно beh: lpadmin -p cm1100beh -E -v beh:/1/0/60/ipp://10.88.144.151/ipp/print -m everywhere

2. Если нужно печатать именно через socket://, для этого требуется PPD/драйвер под язык принтера (у Pantum это собственный Linux-драйвер), driverless-PPD для socket не подходит.

И, пожалуйста, логи заново: в /etc/cups/cupsd.conf добавьте MaxLogSize 0 рядом с LogLevel debug2, systemctl restart cups, затем очистите очередь, отправьте задание, дождитесь зависания, отмените и приложите error_log целиком. Если в результате пункта 1 печать через ipp:// и через beh:/…/ipp:// проходит, баг закроем как ошибку конфигурации.

Created attachment 22141 [details]
beh logs through socket with drivers from vendor and "driverless" driver

>lpadmin -p cm1100 -E -v ipp://10.88.144.151/ipp/print -m everywhere
>lp -d cm1100 /usr/share/cups/data/testprint
При добавлении в таком виде печать корректно работает. 

>Если нужен именно beh: lpadmin -p cm1100beh -E -v beh:/1/0/60/ipp://10.88.144.151/ipp/print -m everywhere
Так добавить нельзя: 
> lpadmin: IPP Everywhere driver requires an IPP connection.
Добавила с драйвером "Pantum CM1100ADW Series, driverless, cups-filters", отработало успешно

При подключении через socket:// backend error handler не отработал и с драйвером от вендора. 

Error_log прилагаю для случаев, когда задание на печать отправлялось через beh с драйвером "Pantum CM1100ADW Series, driverless, cups-filters" - error_log_beh_socket.txt 

и когда задание на печать отправлялось через beh с драйвером от вендора (https://www.pantum.ru/wp-content/uploads/2024/06/pantum-1_1_99-alt3_x86_64-12.zip) - error_log_beh_driver.txt

Итог: через ipp:// и beh:/../ipp:// печать проходит, через beh:/.../socket:// не проходит в том числе с драйверами от вендора

Спасибо, теперь логи полные. Разбор:

1. beh:/1/0/60/ipp://… с PPD "driverless, cups-filters" печатает, ipp:// напрямую печатает. То есть beh как таковой работает, а принтер по IPP исправен.

2. beh:/…/socket:// с driverless-PPD (error_log_beh_socket.txt, задание 18): socket-бэкенд подключился к порту 9100, отправил ~90 КБ Apple Raster, после чего принтер перестал читать данные и завис до отмены задания через полторы минуты. Это ожидаемо: на порт 9100 принтер ждёт свой язык (PCL/PS), а не URF. Такая конфигурация неработоспособна независимо от beh, см. #60382.

3. beh:/…/socket:// с драйвером от Pantum (error_log_beh_driver.txt, задание 21): до сетевого соединения дело вообще не дошло. beh перед запуском настоящего бэкенда полностью читает задание во временный файл, а фильтр вендора ptps за три минуты не выдал ни байта и не завершился. Единственное его сообщение: getsysteminfo: "Debian GNU/Linux 11 (bullseye)". Зависает именно фильтр вендора, а не beh и не socket.

Чтобы понять, виноват ли ptps сам по себе или он не переваривает DEVICE_URI вида beh:/…, нужен один контрольный тест: та же очередь с драйвером Pantum, но напрямую socket://10.88.144.151, без beh. Если так печатает, значит фильтр Pantum разбирает DEVICE_URI и спотыкается о схему beh, это вопрос к Pantum. Если не печатает и так, фильтр вендора не работает на этой системе (он собран под Debian 11), и это тоже не к cups.

Отдельно: отказ lpadmin для beh:/…/ipp:// с -m everywhere ("IPP Everywhere driver requires an IPP connection") это ограничение cupsd, он смотрит на схему URI и не заглядывает внутрь beh. Обход у вас уже есть: PPD "driverless, cups-filters" с beh работает.

> Чтобы понять, виноват ли ptps сам по себе или он не переваривает DEVICE_URI вида beh:/…, нужен один контрольный тест: та же очередь с драйвером Pantum, но напрямую socket://10.88.144.151, без beh. Если так печатает, значит фильтр Pantum разбирает DEVICE_URI и спотыкается о схему beh, это вопрос к Pantum. Если не печатает и так, фильтр вендора не работает на этой системе (он собран под Debian 11), и это тоже не к cups.

Как я понимаю, каким бы ни был результат контрольного теста, это в любом случае проблема на стороне устройства/проприетарного драйвера, а не cups. Соответственно, исправлений со стороны cups не будет. В такое случае, предлагаю закрыть баг как Wontfix. 

Если нужно дополнить баг логами ошибки проприетарного драйвера/устройства - прошу указать, я дополню.

будет будет.

cups-2.4.19-alt2 -> sisyphus:

Tue Sep 08 2026 Anton Farygin <rider@altlinux> 2.4.19-alt2
- Web UI: hide cups-filters driverless PPDs for socket/lpd device URIs,
  such queues cannot print (Closes: #60382)
- Allow the everywhere driver and show driverless PPDs for beh-wrapped
  IPP device URIs (Closes: #60380)