Still can't print after 6 months (Canon MF445dw) -- at the end of my rope

I’ve been trying to get my wireless networked printer (a Canon ImageCLASS MF445dw) working under NixOS for over half a year, and am about to give up and move to another distribution, as my workflow now absolutely demands that I be able to print (scanning would be nice too, but that’s another hill). I’ve installed the device’s driver using the following within configuration.nix,

services = {
    printing = {
      enable = true;
      browsing = true;
      drivers = [ pkgs.canon-cups-ufr2 ];
    };
    avahi = {
      enable = true;
      nssmdns = true;
      publish.enable = true;
      publish.workstation = true;
      publish.addresses = true;
    };
};

I’m on unstable:

$ nix-info -m
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.86, NixOS, 23.05 (Stoat), 23.05pre440068.a518c771485`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.12.0`
 - channels(root): `"home-manager, nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

NixOS CUPS has no problem finding the networked printer, although there is always a curious hiccup in printing a test page, in which CUPS announces it can’t then locate the device it previously found,

"Unable to locate printer "Canon7603ea.local"."

This is the same error as detailed here in a previous post. I don’t know what to make of this apparent communication error, as after a while, CUPS does report completion — without printing anything: CUPS just blithely swallows job after job, reports instant success with a silent printer, not even reporting an error. Perhaps the real issue lies with CUPS/NixOS’s implementation of the driver itself?

In frustration, I even went so far as to

  • create a qemu/kvm Debian 11 image on this NixOS host;
  • install the network printer within that virtual guest machine using Canon’s latest install script, and lo and behold successfully print stuff from within the container;
  • if I share the above functioning printer within the virtual machine, CUPS running under NixOS can find the shared printer OK – although I still must elect to use the Canon driver (supplied by pkgs.canon-cups-ufr2, v. 5.40) – but this route also fails to print anything. Regardless of where it finds the printer, NixOS CUPS just swallows jobs, reports completion, but nothing ever appears at the printer, nor does the printer’s service web page report these job even appearing, whereas successful activity is recorded from print jobs sent within the Debian virtual machine. I had thought that sharing the printer within the container (from which I can print just fine) would work, but native printing from NixOS CUPS doesn’t seem to be possible, only from within a container running within NixOS.

Can anyone suggest what might be happening here? Everything else works great under NixOS, but lacking a printer is turning out to be a real show-stopper, and it seems silly to be limited to printing via software running from within a virtual machine. To repeat – at the risk of extending an already-too-long post – the problem does not appear to be finding the printer, the problem appears to reside within either how the driver is accessed, or some sort of communication issue with the printer itself – i.e., where CUPS believes it’s printing stuff OK, when it’s obviously not.

Sorry again for the long, long post, am just really frustrated with this problem. With every previous distro I’ve used, printing via this device has never ever been an issue. I would be very grateful to any wisdom anyone can provide.


Edited grammar, typos

Don’t know if it might be relevant but the Nixos printing page also has a avahi openFirewall rule?


services.printing.enable = true;
services.avahi.enable = true;

for a WiFi printer

services.avahi.openFirewall = true;

1 Like

@rsa4046 I feel your pain. I have managed to get a HP 7640 printer working on WiFi, then not, then again…

BLUF I had to enable printing and avahi service, then configure in CUPS itself, with the HP JetDirect protocol.

So does the Canon have a similar bespoke protocol? Otherwise, perhaps try opening firewall ports explicitly?

Here is the process I did, in case it helps you or anyone else…

My currently Nixos conf includes this:
services = {
avahi = {
enable = true;
openFirewall = true;
};

(as mentioned elsewhere). I don’t think I did the openFirewall first time around. I also have:

printing = {
  enable = true;

drivers = [ pkgs.hplipWithPlugin ];

};

As in I enable printing, but don’t install the proprietary driver this time (I did first time).

These configs did not “finish” the process of installing a printer…I also tried the complicated scripts to install brother printers

I’m using Gnome, so tried adding a printer in Gnome. It appeared to find a printer, but I couldn’t print.

I went to the CUPS admin and tried IPP and the HP drivers with no success. Then I tried the JetDirect protocol which worked. Or in basically, printing enabled, avahi enabled, manual config via CUPS.

1 Like

Thank you @JosW for this tip: I will check. Am starting to think that avahi functionality is critical to getting initial communication with this printer to work, and am currently playing with strings in a system.nssDatabases.hosts = [ ] statement in configuration.nix, in order to alter the contents of /etc/nsswitch.conf, whose hosts line currently reads

hosts:     mymachines mdns_minimal [NOTFOUND=return] files myhostname dns mdns

This ArchWiki page contains some advice on getting speedier results. I don’t think avahi-daemon is resolving .local hosts correctly fast enough (or else I need to explicitly populate this list). The avahi-daemon reports:

# systemctl status avahi-daemon.service
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/etc/systemd/system/avahi-daemon.service; enabled; preset: enabled)
     Active: active (running) since Sat 2023-01-14 19:36:52 CST; 13h ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 66703 (avahi-daemon)
     Status: "Server startup complete. Host name is biggieNixOS.local. Local service cookie is 157811462."
         IP: 9.9M in, 5.8M out
         IO: 0B read, 0B written
      Tasks: 1 (limit: 57883)
     Memory: 1.3M
        CPU: 6.237s
     CGroup: /system.slice/avahi-daemon.service
             └─66703 "avahi-daemon: running [biggieNixOS.local]"

Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Network interface enumeration completed.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for fe80::fc54:ff:fe75:af25 on vnet0.*.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for fe80::ec4:7aff:fe97:43e5 on enp4s0.*.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for 192.168.0.125 on enp4s0.IPv4.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for fe80::ec4:7aff:fe97:43e4 on enp3s0.*.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for 192.168.0.124 on enp3s0.IPv4.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for ::1 on lo.*.
Jan 14 19:36:52 biggieNixOS avahi-daemon[66703]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jan 14 19:36:53 biggieNixOS avahi-daemon[66703]: Server startup complete. Host name is biggieNixOS.local. Local service cookie is 157811462.

But then ping, e.g., currently issues these curious errors:

# ping biggieNixOS.local
ping: biggieNixOS.local: System error

# ping -v -c 3 biggieNixOS.local
PING biggieNixOS.local(biggieNixOS.local (fe80::ec4:7aff:fe97:43e4)) 56 data bytes

--- biggieNixOS.local ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2065ms

# ping -v -c 3 Canon7603.local
ping: Canon7603.local: System error
# ping -v -c 3 Canon7603ea.local
ping: Canon7603ea.local: System error
# ping -v -c 3 Canon7603ea.local
PING Canon7603ea.local (192.168.0.182) 56(84) bytes of data.
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=1 ttl=64 time=4.17 ms
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=3 ttl=64 time=80.5 ms

--- Canon7603ea.local ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 6060ms
rtt min/avg/max/mdev = 4.173/42.326/80.479/38.153 ms

# ping  -c 3 Canon7603ea.local
PING Canon7603ea.local (192.168.0.182) 56(84) bytes of data.
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=1 ttl=64 time=99.1 ms
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=2 ttl=64 time=116 ms
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=3 ttl=64 time=18.9 ms

So, the system does finally return the printer’s IP after repeated tries, but obviously not fast enough for CUPS. I still don’t understand the other half of the issue – why CUPS thinks these jobs complete OK when the printer never sees them. So evidently I have something fubarred, somewhere. Thanks again for your reply, and I will post back on my results soon.

Thanks, @Damage, for your kind reply. Canon can use the so-called IPP-Everywhere protocol to connect, which I have tried (along with everything else). In the past, I always had good luck connecting HP hardware under Linux using JetDirect.

This is my first Canon laser printer, and only the proprietary driver is available (Canon inkjets OTOH have Linux drivers other than those supplied by Canon). I am running KDE, and as I mentioned above, the printer does install and print flawlessly within a Debian virtual machine (also with KDE) using my NixOS machine as host, so I have been examining this working Debian example in order to determine what is wrong with how NixOS itself communicates with this device (or doesn’t, as the case may be :-/ ).

I will report back my findings.

@rsa4046 - sorry I missed the bit about KDE…

Your comment about avahi made me think of this config I tried when on 22.05 - I thought it helped, but later I could ditch it and everything still worked so I’m not sure. May be worth a try.

settings from avahi-daemon.nix where mdns is replaced with mdns4

system.nssModules = with pkgs.lib; optional (!config.services.avahi.nssmdns) pkgs.nssmdns;
system.nssDatabases.hosts = with pkgs.lib; optionals (!config.services.avahi.nssmdns) (mkMerge [
(mkOrder 900 [ “mdns4_minimal [NOTFOUND=return]” ]) # must be before resolve
(mkOrder 1501 [ “mdns4” ]) # 1501 to ensure it’s after dns
]);

I can’t remember the post for the above, but I think it mentioned some IPv6 issues.

Something I never check when trying IPP (and wish I had) is explicitly opening port 631 (something like this)
networking.firewall = {
allowedTCPPorts = [ 631 ];
allowedUDPPorts = [ 631 ];
checkReversePath = “loose”;
};

I’m hoping you get some success as I want to use IPP in future and it may help me too :slight_smile:

1 Like

Hi @Damage! I just saw your reply – and wish I had checked my mail earlier. I’ve used a very similar fix (i.e., opting for mdns4_minimal and mdns4 and reordering), that I got from this post by @wentasah from 2021-2022 (I don’t why I didn’t find it in earlier searches; I also don’t understand why these changes were apparently not incorporated in 22.11?). Anyway, what I used is essentially what you have above:

{
    services.avahi.enable = true;
    services.avahi.openFirewall = true;
    services.avahi.publish.enable = true;
    services.avahi.publish.addresses = true;
    services.avahi.nssmdns = false; # Use my settings from below
    # settings from avahi-daemon.nix where mdns is replaced with mdns4
    system.nssModules = with pkgs.lib; optional (!config.services.avahi.nssmdns) pkgs.nssmdns;
    system.nssDatabases.hosts = with pkgs.lib; optionals (!config.services.avahi.nssmdns) (mkMerge [
      (mkOrder 900 [ "mdns4_minimal [NOTFOUND=return]" ]) # must be before resolve
      (mkOrder 1501 [ "mdns4" ]) # 1501 to ensure it's after dns
    ]);
  }

After these changes, bingo! The system can locate these .local hosts without difficulty:

$ ping -v -c3 Canon7603ea.local
PING Canon7603ea.local (192.168.0.182) 56(84) bytes of data.
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=1 ttl=64 time=48.5 ms
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=2 ttl=64 time=100 ms
64 bytes from 192.168.0.182 (192.168.0.182): icmp_seq=3 ttl=64 time=21.5 ms

--- Canon7603ea.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6068ms
rtt min/avg/max/mdev = 21.532/56.782/100.336/32.702 ms

So, after deleting/adding the printer again, letting CUPS detect the printer:

dnssd://Canon%20MF440%20Series._ipp._tcp.local/?uuid=6d4ff0ce-6b11-11d8-8020-00bbc17603ea

and selecting the canon-cups-ufr2 driver, still no joy :sob:: CUPS just swallows jobs and reports success without any actual printer activity.

HOWEVER I can circumvent this by at least saving output as .pdf files and using lpr for printing: that does work, thank goodness. Not seamless, but at least functional :slight_smile: .

So it seems there is still some serious problem with communication here – and unfortunately I don’t understand enough about CUPS to get this right on my own. But at least I can print (sort of) :stuck_out_tongue_winking_eye:

I’m very grateful for your help!

1 Like

Interesting - when I upgraded to 22.11 I commented out those lines to see if it had been updated and the printer carried on working (I can’t remember if I was using JD at the time). so I thought it had been fixed for 22.11
Looking at packages, I wonder if avahi-compat might help. The nee-mdns page GitHub - avahi/nss-mdns claims avahi is a hard dependency, so I wonder if nss-mdns gets installed by that script rather than by enabling avahi itself? There also seem to be documented behaviour with IPv6 and also .local addresses (I do not use .local).
So I wonder if using the IP address might be a quick fix to help with files other than PDF (which is so weird!). Also using pkgs.nssmdns and/or configuring nss-mdns itself may be needed - I am starting to understand that sometimes a very minimal nix config and doing the config in the desktop envionment may yeild result - but I still can’t work out which one is the right one to change to make elements such as printing work!
Good luck if you pursue this further…

1 Like

I also don’t understand why these changes were apparently not incorporated in 22.11 ?

That’s because it would break mDNS on IPv6 networks. As far as I remember, the problem is caused by combination of two things: 1) NixOS doesn’t cache responses in nscd (I’m not sure why) and 2) lengths of timeouts in CUPS and/or Avahi.

I didnd’t find time to investigate this in more detail. But given that nobody else did, I might try looking at that again.

@wentasah thanks for this insight.

@rsa4046 Just to add I have noticed the cups-bjmp package…from the nixos search:

“CUPS back-end for the canon printers using the proprietary USB over IP BJNP protocol. This back-end allows Cups to print over the network to a Canon printer. The design is based on reverse engineering of the protocol.”

Don’t know if this helps or hinders…

Hi @Damage, will look into this, thanks!

Just out of curiosity, please try setting services.printing.stateless = true. I made this option a while ago. It will nuke all of the state in /var/lib/cups, which usually people don’t want or need, and usually leads to cups having errors with mDNS, in my experience. If that doesn’t work, please watch the following video

5 Likes

Thanks @matthewcroughan — That video is just hilarious!

I just noticed that NixOS doesn’t provide sane defaults for CUPS because CUPS itself doesn’t have sane defaults.

For example by default the ErrorPolicy is set to stop-printing. That means if a print job ever fails for any reason, CUPS will deactivate the entire printer indefinitely until you manually resume the printer via the cmdline or webinterface.

If your printer says paused in the webinterface, then this is the case.

For reference, ubuntu seems to use better defaults here.
ubuntus /etc/cups/cupsd.conf:

LogLevel warn
PageLogFormat

# Specifies the maximum size of the log files before they are rotated.  The value "0" disables log rotation.
MaxLogSize 0

# Default error policy for printers
ErrorPolicy retry-job

# Only listen for connections from the local machine.
Listen localhost:631
Listen /run/cups/cups.sock

# Show shared printers on the local network.
Browsing No
BrowseLocalProtocols dnssd

# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Web interface setting...
WebInterface Yes

# Timeout after cupsd exits if idle (applied only if cupsd runs on-demand - with -l)
IdleExitTimeout 60

# ... truncated

I never did get this printer driver to work, and currently depend on the printer hardware to print pdf files via raw LPR. IOW, the only way I can print anything is via lpr -l (or saving to pdf and then lpr -l file.pdf). The -l option “specifies that the print file is already formatted for the destination and should be sent without filtering. This option is equivalent to -o raw”. Of course, I believe I also lose any and all functionality supplied by the Canon driver. If I send files to this driver (canon-cups-ufr2), cups filtering doesn’t seem to work at all, i.e., the job just disappears — instantly, and the proprietary web interface for the (wireless network) printer doesn’t even record a job: apparently the printer never sees it, although cups reports success.

I don’t think this is a network problem, I think it’s a cups problem. E.g., I can login to the printer’s web interface mentioned above using the name assigned by cups (http://canon7603ea.local/), and query print jobs, toner level, etc. Let’s say I have a 24Kb pdf file. If I try to print from a KDE application, say okular, cups accepts the job, instantly declares the job a success after it logs sending 210Kb (?). But this job is never recorded by the printer itself — the web interface log shows no activity. If I print from the CL (or send to ‘lpr -l’), the file prints just fine, cups logs that a 24Kb file was successfully sent, and of course the web interface records the job, correct file size, filename, etc.

I’m certainly no expert on drivers or cups. But to me, the above behavior suggests some basic lack of function with my NixOS implementation of cups and its filtering, functionality that Canon supplies and ensures when it installs its own cups routines (provided in either rpm or deb formats for 64-bit Linux systems). But I don’t think there is any easy way of allowing the factory driver installation routine to work under NixOS (and I know that the factory driver setup works because of previous success with both Fedora or Debian).

So, long-story-short: So I’ve given up trying to realize any functionality with this printer under NixOS beyond what I describe above.

I feel you.

I have a Canon iSensys MF655Cdw. I have also tried various combinations for existing drivers in the canon-cups-ufr2, since the MF655Cdw / MF650 Series is not part of that collection. I also experienced “No toner left” error messages as well as jobs being submitted but never reaching the printer, even grayscale would have been a small win.

I can also not install the drivers supplied by Canon as it is mainly RPM and DEB packages and the ./install just fails miserably.

What a pity.

@wynandm I should have updated this post, as I finally did get the printer to be be fully functional, but more or less by accident. I can post the relevant parts of configuration.nix, but in essence I enable printing, but that’s it: I don’t declare the driver at all (see below). I will post more about this setup, particularly re setting it up in cups, later today:

services= {
...
    printing = {
      enable = true;
#     drivers = [ pkgs.canon-cups-ufr2 ];
    };
...
};

But I think you can get it to work.

1 Like

@wynandm
To finish up the previous post, the relevant part (really just one line) of my configuration.nix is above. Also (and I’m not really sure this is important), I’m running unstable. After almost a year fighting with trying to install the driver manually, hacking the .deb/.rpm files supplied by Canon, etc., I had given up, removed every vestige of the printer from my configuration, but left the printing (cups) service enabled in order to be able to print to pdf.

I had also left avahi enabled as well (imported as a separate file):

  { config, lib, pkgs, ... }: {
    services.avahi.enable = true;
    services.avahi.openFirewall = true;
    services.avahi.publish.enable = true;
    services.avahi.publish.addresses = true;
    services.avahi.nssmdns = false;
    system.nssModules = with pkgs.lib; optional (!config.services.avahi.nssmdns) pkgs.nssmdns;
    system.nssDatabases.hosts = with pkgs.lib; optionals (!config.services.avahi.nssmdns) (mkMerge [
      (mkOrder 900 [ "mdns4_minimal [NOTFOUND=return]" ]) # must be before resolve
      (mkOrder 1501 [ "mdns4" ]) # 1501 to ensure it's after dns
    ]);
  }

I assume the statement,
services.printing.enable = true;
automatically adds the necessary bits from cups, as cups is nowhere declared explicitly.

At this point, after removing the driver reference,
drivers = [ pkgs.canon-cups-ufr2 ];
from my configuration.nix, I had expected the printer to disappear from the system, but to my amazement cups found and configured the printer itself, choosing a “driverless” configuration, which seems to work just fine. Here’s what cups reports at http://localhost:631/printers/Canon_MF440_Series


Description: Canon_MF440_Series
Location:
Driver: CNMF440 Series, driverless, cups-filters 1.28.17 (color, 2-sided printing)
Connection: implicitclass://Canon_MF440_Series/
Defaults: job-sheets=none, none media=na_letter_8.5x11in sides=one-sided

And here’s the status of the various cups daemons:

$ systemctl status cups.socket cups-browsed.service cups.service
● cups.socket - CUPS Scheduler
     Loaded: loaded (/etc/systemd/system/cups.socket; enabled; preset: enabled)
    Drop-In: /nix/store/m9dyjxib3fbxdq6kcpfr1rkva4vzc87g-system-units/cups.socket.d
             └─overrides.conf
     Active: active (running) since Thu 2023-08-24 15:22:27 CDT; 1h 18min ago
   Triggers: ● cups.service
     Listen: /run/cups/cups.sock (Stream)
             127.0.0.1:631 (Stream)
         IP: 0B in, 0B out
         IO: 0B read, 0B written
      Tasks: 0 (limit: 57871)
     Memory: 8.0K
        CPU: 517us
     CGroup: /system.slice/cups.socket

Aug 24 15:22:27 biggieNixOS systemd[1]: Listening on CUPS Scheduler.

● cups-browsed.service - CUPS Remote Printer Discovery
     Loaded: loaded (/etc/systemd/system/cups-browsed.service; enabled; preset: enabled)
     Active: active (running) since Thu 2023-08-24 15:22:54 CDT; 1h 18min ago
   Main PID: 1713 (cups-browsed)
         IP: 221.6K in, 6.0K out
         IO: 7.5M read, 48.0K written
      Tasks: 4 (limit: 57871)
     Memory: 6.8M
        CPU: 168ms
     CGroup: /system.slice/cups-browsed.service
             └─1713 /nix/store/madrmm91biki8x560a07nhxwbw0h432f-cups-filters-1.28.17/bin/cups-browsed

Aug 24 15:22:54 biggieNixOS systemd[1]: Started CUPS Remote Printer Discovery.

● cups.service - CUPS Scheduler
     Loaded: loaded (/etc/systemd/system/cups.service; linked; preset: enabled)
    Drop-In: /nix/store/m9dyjxib3fbxdq6kcpfr1rkva4vzc87g-system-units/cups.service.d
             └─overrides.conf
     Active: active (running) since Thu 2023-08-24 15:23:03 CDT; 1h 18min ago
TriggeredBy: ● cups.socket
       Docs: man:cupsd(8)
    Process: 1773 ExecStartPre=/nix/store/1dhyhnmscx0dx2pa43m1qbdabimnzfnr-unit-script-cups-pre-start/bin/cups-pre-start (code=exited, status=0/SUCCESS)
   Main PID: 1811 (cupsd)
     Status: "Scheduler is running..."
         IP: 5.8K in, 30.6K out
         IO: 7.8M read, 88.0K written
      Tasks: 2 (limit: 57871)
     Memory: 7.3M
        CPU: 186ms
     CGroup: /system.slice/cups.service
             ├─1811 /nix/store/9jfwkrzdhy66xj1cgk6abqmp4gjb5q0s-cups-2.4.6/sbin/cupsd -l
             └─1914 /nix/store/75qk53f4c4y40xkzklriqpgw80wi1q75-cups-progs/lib/cups/notifier/dbus dbus://

Aug 24 15:23:34 biggieNixOS cupsd[1811]: Saving printers.conf...
Aug 24 15:23:34 biggieNixOS cupsd[1811]: Generating printcap /etc/printcap...
Aug 24 15:23:34 biggieNixOS cupsd[1811]: Saving subscriptions.conf...
Aug 24 15:25:22 biggieNixOS cupsd[1811]: REQUEST localhost - - "POST / HTTP/1.1" 200 562 Create-Printer-Subscriptions successful-ok
Aug 24 15:25:53 biggieNixOS cupsd[1811]: Saving subscriptions.conf...
Aug 24 16:23:42 biggieNixOS cupsd[1811]: Subscription 214 has expired...
Aug 24 16:23:42 biggieNixOS cupsd[1811]: REQUEST localhost - - "POST / HTTP/1.1" 200 183 Renew-Subscription successful-ok
Aug 24 16:24:13 biggieNixOS cupsd[1811]: Saving subscriptions.conf...
Aug 24 16:27:28 biggieNixOS cupsd[1811]: [Client 9] Started "/nix/store/75qk53f4c4y40xkzklriqpgw80wi1q75-cups-progs/lib/cups/cgi-bin/printers.cgi" (pid=7509, file=15)
Aug 24 16:30:23 biggieNixOS cupsd[1811]: [Client 9] Started "/nix/store/75qk53f4c4y40xkzklriqpgw80wi1q75-cups-progs/lib/cups/cgi-bin/printers.cgi" (pid=7598, file=15)

So, in the end, I ended up doing nothing explicit with respect to the printer, printer driver, etc., and it worked. I don’t know if this was a result of bug fixes subsequent to my earlier attempts, so I really don’t know how this was problem was “solved”. But the “driverless” configuration does work, prints cups test pages OK, etc., and incidentally also seems to be the configuration used by MacBooks that connect to this same printer. I can post the rest of my NixOS configuration if that would be of any help, but I think most of that is irrelevant.

Hope this helps, and hope you get your MF655Cdw to print from NixOS. My sense is that if mine worked, yours should too.

4 Likes

Thanks so much for this detailed feedback, seems there might be some light at the end of the tunnel.

I will take my time and investigate your post and try your suggestions over the weekend. What I have already noticed that is very different from my previous attempts is the use of Connection: implicitclass:// where all my previous attempts where ipp:// or http://

No need to paste your full config, I suspect the amount of breadcrumbs you have left here should be sufficient for me to figure out how to get it working. If not, then my “nix-fu” is not strong enough and I need more training :slight_smile:

I appreciate your feedback.

1 Like