Print Server Issues

[Marsi4eg]

I have already written about usb print server 'death' after some time of printer's inactivity. (Asuswrt-Merlin 378.52 is available)
Re-plugging a printer helps but only for ONE printing. (need to replug every time I need to print).
After a few days even replugging doesn't help. Everytime there is an error that the printer is busy, Print server stucks with the name of connected printer even if it's powered off long time ago.
Also the print server dies if no printer was connected and the uptime is long. New connections just doesn't work.

This is NOT a compatibility issue! Print server works fine and IS compatible with my printer after restarting the router. And something goes wrong (it becames incompatible?) after some time.

I have rolled back my second router (N16) to 374.43 because I clearly remember that all was fine with that firmware. And that's true - no issues with 374.43 firmware.

Tested for 4 days and everytime I could print. The printer correctly detects, every printing task is logged reporting current printer state. Works like a clock. The log is beautiful:

May 10 23:02:55 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 3
May 10 23:02:55 kernel: usb 1-1: configuration #1 chosen from 1 choice
May 10 23:02:55 kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04E8 pid 0x3272
May 10 23:02:55 kernel: drivers/usb/class/usblp.c: usblp0 Device ID string [59]='MFG:Samsung;CMD:SPLC;MDL:CLP-300;CLS:PRINTER;STATUS:BUSY;'  // warm-up
May 10 23:04:00 kernel: drivers/usb/class/usblp.c: usblp0 Device ID string [59/max 1552]='MFG:Samsung;CMD:SPLC;MDL:CLP-300;CLS:PRINTER;STATUS:IDLE;'  // sent first task
May 10 23:04:00 kernel: drivers/usb/class/usblp.c: Parsing USBLPID...
May 10 23:11:02 kernel: drivers/usb/class/usblp.c: usblp0 Device ID string [59/max 1552]='MFG:Samsung;CMD:SPLC;MDL:CLP-300;CLS:PRINTER;STATUS:IDLE;'  // second task
May 10 23:11:02 kernel: drivers/usb/class/usblp.c: Parsing USBLPID...
May 10 23:17:14 kernel: drivers/usb/class/usblp.c: usblp0 Device ID string [59/max 1552]='MFG:Samsung;CMD:SPLC;MDL:CLP-300;CLS:PRINTER;STATUS:IDLE;'  // third etc.
May 10 23:17:14 kernel: drivers/usb/class/usblp.c: Parsing USBLPID...
May 10 23:18:28 kernel: drivers/usb/class/usblp.c: usblp0 Device ID string [59/max 1552]='MFG:Samsung;CMD:SPLC;MDL:CLP-300;CLS:PRINTER;STATUS:IDLE;'
May 10 23:18:28 kernel: drivers/usb/class/usblp.c: Parsing USBLPID...
May 10 23:40:02 kernel: usb 1-1: USB disconnect, address 3  // powered off

The other interesting thing that ASUS Device Discovery tool shows that my AC66U have a connected printer even if it does not. At the same time, WebUI of router doesn't show any connected device. Looks like print server is really getting stuck in some state and cannot recognize when the new printer or the same one is connected again, and reports 'Device is busy' error.

So please RMerlin, I know that you cannot test this properly by your side - I could help in testing. Maybe you could take a look and merge some code from the older release, to make printserver work again. I already were making tests for more than two weeks to figure something out - and I think I did this... the next step is to look into the code but I'm not a good programmer

 

[john9527]

There was a fix that Merlin picked up for 'slow' USB connected printers. I picked up sort of a 'hybrid' version of this fix in my fork (part of the fix was a kernel change, which I had problems with). Can you test with my fork (based on 374.43) to see if it exhibits the problem?
http://www.snbforums.com/threads/fork-update-for-374-43-available.18914/

 

[RMerlin]

There was a fix that Merlin picked up for 'slow' USB connected printers. I picked up sort of a 'hybrid' version of this fix in my fork (part of the fix was a kernel change, which I had problems with). Can you test with my fork (based on 374.43) to see if it exhibits the problem?
http://www.snbforums.com/threads/fork-update-for-374-43-available.18914/

Did you keep this fix?

https://github.com/stsichler/asuswrt-merlin/commit/34dddd800e29cbfd690fabb0cc19bac3c8afe9a3

The author reverted that fix after he had backported the 2.6.36 lpr driver back on top of 2.6.22 (the fix which you reverted). If the kernel level fix is broken, then I would assume that switching to this userspace fix might be a solution - unless it breaks the 2.6.36 kernel users...

This is another example why a one-man team (myself) simply cannot deal with those features that involve outside devices, be it printers or USB modems, and what happens if I try to touch that part of the code (even when it's through pull requests coming from knowledgeable developers). I don't have the time nor the resource to test hundreds of different devices, each with their particular quirks. Asus has a whole team of developers to work on this, and millions to spend on test devices. That fix resolves a particular issue, but now I hear it creates a different issue for other users. So, if the provided fix causes new issues, the most likely path I'd take is revert that fix, and tell people with the original issue (which that fix was meant to address) to contact Asus instead.

 

[john9527]

Did you keep this fix? ....
The author reverted that fix after he had backported the 2.6.36 lpr driver back on top of 2.6.22 (the fix which you reverted). If the kernel level fix is broken, then I would assume that switching to this userspace fix might be a solution - unless it breaks the 2.6.36 kernel users...

That's exactly what I did when the kernel fix wouldn't compile for me. Used that previous fix instead.

I haven't had any complaints on the fork, but who knows if anyone has a printer connected.....

 

[RMerlin]

That's exactly what I did when the kernel fix wouldn't compile for me. Used that previous fix instead.

Odd, I haven't had any other report of compile failure.

I haven't had any complaints on the fork, but who knows if anyone has a printer connected.....

I've never received any feedback at all following the release of a beta that included those fixes either. That was the first piece of feedback I've had, and it's been weeks since the original beta with that merge came out.

Considering that most modern printers are now shipping with wifi support (except the very low-end ones, which might not work at all under Linux anyway), this is one of these features that doesn't have a bright future either, so I'm most likely going to go down the simplest route to simply "shelve" the issues related to it.

 

[john9527]

Odd, I haven't had any other report of compile failure.

I was surprised myself....but I remember I tried it as a cherry-pick (which worked without conflicts), then double checked it line by line when it wouldn't compile. I admit I didn't spend more time than that. One thing I'm seeing now in maintaining the fork is more and more dependencies on things you pick up in the big merges you do....maybe there was something else I needed.

 

[Marsi4eg]

There was a fix that Merlin picked up for 'slow' USB connected printers. I picked up sort of a 'hybrid' version of this fix in my fork (part of the fix was a kernel change, which I had problems with). Can you test with my fork (based on 374.43) to see if it exhibits the problem?
http://www.snbforums.com/threads/fork-update-for-374-43-available.18914/

Interesting, I'll test this, thanks. I'll try it on my *testing* N16, it's basically the same as AC66U so actually result must be the same for other models

Odd, I haven't had any other report of compile failure.

Maybe not so many people are using usb printer.. If you could include that fix in a beta, and point users to test their printers if thay do use, we can get some useful feedback.

I'll post here later today about fork testing result

 

[RMerlin]

Interesting, I'll test this, thanks. I'll try it on my *testing* N16, it's basically the same as AC66U so actually result must be the same for other models


Maybe not so many people are using usb printer.. If you could include that fix in a beta, and point users to test their printers if thay do use, we can get some useful feedback.

I was referring to the compile issue John encountered, not the router functionality.

And BTW, last time I posted a beta asking for feedback on USB printer support, I got zero feedback. I don't see why that would be different now.

 

[Marsi4eg]

I have tested... It works perfectly

 

[john9527]

I have tested... It works perfectly

Thanks for the feedback. While not conclusive that the kernel mode fix may have a problem, at least the userspace fix appears to not have an unexpected side effect.

 

[ILMostro]

I'm experiencing this issue right now with the 378.55_beta1 FW and my USB2.0-connected printer. It's shows up as "ready" in RHEL7 w/GNOME, but no sign on the printer side of activity when I send a job. It continues to show "Processing" on the PC side. No messages in router's `dmesg`.

 

[KUHOTEXHUK]

Hi there!
Got the same problem with malfunctioning printer connected via USB to the router.
For about a year it worked pretty well, but after one of the firmware upgrades it refused to print. Unfortunately i did not link it to firmware upgrade because by that time i didn't print much, so i thought it was some other problem. Tried resetting the router, restoring it to defaults, etc.
All these were made while runnig original firmware. After some time i understood it was related to upgrade i made, but for the time ther had been several updates released and i couldn't realise which one was working before. One of the steps was moving to Merlin's firmware to try whether this problem is firmware-dependent.
Later i found this thread and as TS mentioned rolled back to v.374.43 and everything is working fine now. Therefore something has changed pretty much after this firmware

If there is anything i can do to help you eliminate this problem - any tests and experiments - i'm all yours =)

ASUS RT-N66U + HP LaserJet P2055d

 

[Marsi4eg]

After all, more than a year I use my old DIR-320 A1 in AP mode, connected to main AC66U, as a compatible print-server, and it works great. So I stopped to use Asus' print-servers because of these magic unfixable compatibility bugs.

 

[Marko Polo]

It seems I have the same issues on AC68-U and Merlin 380.68_4. The printer prints one-two pages and then dies, after that only router reboot helps.
I tried to plug-unplug the printer, but that didn't help.

Nov 29 19:06:56 kernel: usb 1-2: new high speed USB device using ehci_hcd and address 4
Nov 29 19:06:56 kernel: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04E8 pid 0x330C
Nov 29 19:10:38 kernel: usb 1-2: USB disconnect, address 4
Nov 29 19:10:38 kernel: usblp0: removed
Nov 29 19:10:41 kernel: usb 1-2: new high speed USB device using ehci_hcd and address 5
Nov 29 19:10:41 kernel: usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x04E8 pid 0x330C

Rebooting the printer for each page is not cool. Any solution?

 

[Marko Polo]

No solution? This problem is rather crucial.

 

[just4sc]

Problem still exist in 386.3_2 on RT-AX86U. Any work arounds? I've been able to print by turning the print server off and then back on. But that's kind of annoying.

 

[L&LD]

Welcome to the forums @just4sc.

Did you read this thread? And post 3 by RMerlin? From 2015...

 

[L&LD]

This may be applicable too.

September 2021 Patch Tuesday ruins network printing on Windows

Even when there's not PrintNightmare, there's still a print nightmare.

www.windowscentral.com

 

[just4sc]

Sorry, no...I went straight to the end of the thread thinking the solution would be there. Thanks.

Welcome to the forums @just4sc.

Did you read this thread? And post 3 by RMerlin? From 2015...