So, first we’ll address the elephant in the room: yes, I know I haven’t posted since like September. The last quarter of 2025 was a bit of a whirlwind. Here’s a (probably not complete) list of things that have happened, just to catch you up from ~September ’til now:

  1. Got married. Yes, I know, someone actually agreed to that? I’m just as surprised as you are.
  2. Started a new role. Same company, different team, different role. I’ve moved into Threat Intelligence - an oft forgotten part of CyberOps. An area of Cyber that is still not understood because it’s so nuanced.
  3. Replaced my front and back doors. It was expensive.
  4. Replaced my garage door. It was also expensive.
  5. Screened in my back patio. It was less expensive, but still not something I’ve financially recovered from because I am terrible at managing timelines.
  6. Implemented OpnSense on my network, along with OpenVPN, ELK stack, and some other stuff. It works.
  7. Probably some other stuff I’m not remembering that may or may not be important.

Anywho, so yeah. Busy. So what’s this post gonna be about? A very specific, recent, challenge I overcame: printer shenanigans. The bane of IT. The scourge of networks. The… {insert some other clever thing here}.

So, backstory: we’ve had a printer for a while, as most people do. Ours is an Epson EcoTank 2800. It’s neat, it works, I liked to pretend it didn’t exist because I hate dealing with printers. There was one issue that was a constant thorn though: it had a propensity to go to sleep, and when it would, it sometimes wouldn’t reconnect to the network by itself so it had to be reconnected to the network.

Normally this isn’t an issue, you can just plug in an ethernet cable, connect it to a switch, give it a static IP, and you’re good to go. Problem is this printer doesn’t have an ethernet port. So there wasn’t really a good solution to the problem. My wife assured me that it was fine - she didn’t mind having to reconnect it when she needed to print. She didn’t consider it an issue. I did. And in classic me fashion I decided to do something about it, but in an absolutely unnecessary and over-engineered way.

“Okay… so what’d you do?” Glad you asked! I took a RaspberryPi 4 that was just sitting idle on a shelf and installed CUPS on it, plugged the printer into the Pi via USB, and figured after doing the bare minimum configuration that I was done. Oh dear reader, how vain I was. How naive. You see, it was not that simple. In fact, the printer not accepting print jobs was just the appetizer. We were about to sit down for a 15 course meal of pain and tomfoolery that still makes me question if it was all worth it or not.

I should take this moment to let you know that I worked on this issue over approximately 2 days/nights, so my memory is a bit hazy as to the timeline of things, what was broken first, what was fixed first, etc so we’re gonna just take a 10,000 ft look at the myriad of problems we ran into and address the absolute shenanigans involved in fixing them.

Issues: The “broken pipe” error - ft undervoltage errors

When I finally got the printer connected and visible in the CUPS UI, I was unable to successfully print anything, even from a computer that was on ethernet. CUPS repeatedly gave error 32 (Broken Pipe) and client-error-not-authorized errors. In addition to these, dmesg was reporting Undervoltage detected followed by usb reset events. To top all of this off, Windows was throwing a 0x00000709 error.

So. We have like 5 issues. No idea where to start. No idea what half of that even means. But we have a (dwindling) will so we’re gonna find a way!

Solutions

The undervoltage issues were being caused because the Pi was running off of a USB port on another computer, and then a USB connected to a phone charger. Neither of these were providing the necessary voltage needed to handle the spikes that occurred when the printer’s motor initialized, so instead of attempting to do anything, the CUPS service failed out and reset the connection mid-transfer. The solution here was to dig out a dedicated 5.1v Pi charger and plug the Pi in using that. No more errors or resets.

We were still seeing the broken pipe errors, the client not authorized errors, and the Windows error code. So I had to figure out what was going on here now that the Pi was done complaining about electricity. These issues were all kind of related, it had to do largely with how CUPS (which is a Unix-based backend to manage print spoolers) and Windows 11 were attempting to speak to each other. CUPS would establish a connection, Windows would reply in a way that CUPS did not understand, so CUPS simply dropped the connection. Part of the issue was that CUPS was using the wrong interface for the printer. For whatever reason ipp-usb was grabbing the printer port, so I had to disable it (and eventually just straight up uninstall) in order to get it to give the port back to CUPS so it could be managed properly. Once this was sorted I was able to assign the printer in CUPS to use the actual USB interface it was plugged into. This still didn’t solve the communication issue, but it got us closer. Instead of speaking French and Chinese, we were at least speaking French and Spanish now. Instead of trying to fiddle with filters and other things I don’t understand, I decided to take a much easier route: just set the printer to a RAW format so that any octet streams Windows gives it are just read as straight raw data. I made a raw.types and raw.convs in /etc/cups, ensured that <Local /printers> had the @LOCAL allow block in cupsd.conf, and we were finally getting somewhere. Now the issue was almost squarely on the Windows side (well, sort of). Windows was still failing to properly connect and transmit to CUPS, but it was less an issue with the data and more an issue with the middleman: Nginx Proxy Manager. The root cause of the unauth errors were actually HTTP/2 errors caused by NPM not properly handling and forwarding the request. Instead of actually trying to solve this, I just bypassed it and set the printer up on Windows to talk to the IP of the Pi and hit the printers/{printer} area of CUPS, which we just made sure was allowed above in the cupsd.conf file.

Issues: “Broken pipe” returns - but in a less annoying way?

We had progress, but once the communication streams were actually talking, CUPS was still killing the connection mid way through. Turns out that the Pi was to blame this time, it was hitting a TCP timeout and failing about halfway through the connection. This can happen on larger files or larger data transfers, but this was happening on a test page, so I still have no clue why the Pi was doing this. The solution wasn’t too bad though. Three commands:

sudo sysctl -w net.ipv4.tcp_keepalive_time=60  
sudo sysctl -w net.ipv4.tcp_keepalive_intvl=10  
sudo sysctl -w net.ipv4.tcp_keepalive_probes=6

Setting those on the Pi seemed to let the connection say alive long enough for a test print to work. But now we were running into another issue: a multi-page print still fails, at least until you restart CUPS. I firmly believe this issue was on Windows but I adjusted some variables in cupsd.conf and it seems to have solved the issues. Here are the adjustments I made:
MaxRequestSize 0 - disables size limit for incoming jobs. This was tuned because we’re using the raw stream, and that can get pretty large.
MaxClients 500 - one issue I saw was a “Max clients reached” message, which was effectively a self-inflicted DoS, so I set it to a high-ish arbitrary number to prevent that. I’m never going to have 500 clients at once, so this is just dealer’s choice.
IdleExitTimeout 60 - for whatever reason there were weird hangups that seem to be related to this being an InkJet-adjacent printer. I still don’t fully understand this one, but without it I get errors.

Issues: Windows hates drivers

This one is pretty self-explanatory. Windows hates drivers. For whatever reason Microsoft deems it necessary to not include generic drivers anywhere by default. You have to let Windows Update “search” for them. I figured setting the printer to be a raw queue device would bypass this and let me use a generic IPP driver, but nope. Microsoft doesn’t let that happen. So I had to go fetch the actual Epson driver and install it. For Linux and Mac devices though, the generic IPP driver works fine.

So yeah. That’s how all that went. Like I said, I’m probably forgetting some stuff - there were a lot of issues. That’s fine though, this isn’t meant to be a walk through or a “how-to” document, it’s more of a rant. Though, that said, if you do happen to run into similar issues, this might help still.

I also went ahead and installed Avahi, which just kinnda works by default so that Linux and Mac can just find the printer over the network with no fuss using whatever protocol they feel like using that hour. No issues there (yet).

At the end of the day(s), everything now finally works. Printer is on, I can manage its settings and queues in CUPS UI, people can print over the network, regardless of what type of device they’re on. Oh, another quick thing: if your’re using a wifi only printer, you’re gonna want to disable the wifi completely so that the wifi driver doesn’t try to usurp the Pi in network communication. This will render your printer’s default web interface entirely inoperable and in order to get that back you’ll have to factory reset your printer, but it is what it is.


So, looking back, would I do this again? Absolutely not. Did I learn anything? Yeah, kinda. Was what I learned at all applicable outside of this niche scenario? Nope. Do I suggest this as a “fun” weekend project for anyone? Sure, if you have a therapist on speed dial and hate yourself that much. But like you could also get a similar outcome from watching the news or playing Dark Souls on a DDR dance pad, so I’d advise doing that instead.

So, all that said, that’s it for now. Maybe I’ll update again before the end of this year lol