Tag Archives: troubleshooting

Brother DCP-T426W wouldn’t print on Linux/Debian: ipp-usb conflicts with vendor driver

Leave a reply

TLDR: If you’re using a manufacturer-provided CUPS driver (Brother, Canon, etc.) and your printer silently refuses to print, check whether ipp-usb is running. It’s a well-intentioned daemon for driverless printing, but it directly conflicts with legacy vendor drivers that expect raw USB access. Mask it, point your queue at the right URI, and you’re done.

I again installed the Brother DCP-T426W driver on my Debian Trixie, connected the printer via USB, sent a test page. The job just sat there with “Waiting for printer to become available.” Occasionally, it gets printed but most of time, it just waiting there. To make matter worse, the scanner was working fine and I could scan using a Debian machine! Printing test page would often work but not always!

Running lpstat -p showed two printer queues had been created:

  • Brother_DCP_T426W_USB — using implicitclass:// (driverless IPP)
  • DCPT426W — using usb://dev/usblp0 (Brother’s native driver)

The CUPS error log showed the driverless queue failing with “No IPP attributes“, and the Brother queue stuck because /dev/usblp0 didn’t exist.

dmesg revealed the real culprit: the kernel device usblp3 was being created and destroyed every 5 seconds in a loop. And systemctl status ipp-usb confirmed the ipp-usb daemon was running.

Modern Linux systems ship with ipp-usb, a daemon that intercepts USB printers supporting the IPP over-USB protocol and exposes them as network printers. The DCP-T426W supports this protocol, so ipp-usb grabbed the device the moment it was plugged in.

This created a conflict: the Brother CUPS driver expected to talk directly to /dev/usblp0, but ipp-usb was sitting in between, cycling the connection every 5 seconds. Neither driver could win. On top of that, the queue URI was pointing to /dev/usblp0 — which never existed. The actual device node was /dev/usb/lp3.

Thanks AI for explaining this to me.

The Fix Three steps:

  1. Stop and mask ipp-usb so it no longer intercepts the printer on this or future boots: sudo systemctl stop ipp-usb and sudo systemctl mask ipp-usb
  2. Find the correct USB URI using lpinfo: sudo lpinfo -v direct usb://Brother/DCP-T426W?serial=XXXXXXXX
  3. Update the printer queue to use the correct URI:
    sudo lpadmin -p DCPT426W -v "usb://Brother/DCP-T426W?serial=XXXXXXXX"
    sudo lpadmin -d DCPT426W

After that, the test page printed immediately.

psql: FATAL: role “root” does not exist.

Leave a reply

I was using healthcheck in postgres container which triggered this ominous error.

I made the following changed and the problem went away (for obvious reason, I guess) — pg_isready needs to know which user is being problem.

Following is the diff.

index 4c91dcc..89ad702 100644
--- a/compose.yaml
+++ b/compose.yaml
@@ -6,8 +6,9 @@ services:
     shm_size: 512mb
     environment:
       POSTGRES_PASSWORD: test_postgres_123
+      POSTGRES_USER: test_postgres_user
     healthcheck:
-      test: ['CMD-SHELL', 'pg_isready' ]
+      test: "pg_isready -U $$POSTGRES_USER"
       interval: 1s
       timeout: 5s
       retries: 10

Thanks https://stackoverflow.com/questions/60193781/postgres-with-docker-compose-gives-fatal-role-root-does-not-exist-error