On a recent OpenWRT trunk build (now using r36346, kernel 3.8.7) I get intermittent connection reset errors, after which the print job stalls:
Apr 16 19:20:28 router lpr.notice p9100d[3579]: Connection from 192.168.196.1 port 49741 accepted
Apr 16 19:21:04 router lpr.notice p9100d[3579]: Finished job: 431113 bytes received
Apr 16 19:21:04 router lpr.err p9100d[3579]: copy_stream: Connection reset by peer
I tried both bidirectional and unidirectional mode, with and without -i option, nothing helps. The same p910nd (0.95) worked fine on older (3.6-) kernels. The connection reset occurs in about 75% of all print jobs.
Btw, I am using an HP Photosmart D5460 connected via USB on a Netgear WNDR3700v1 router.
I'm unable to replicate the problem on my x86_64 version of p910nd running kernel 3.7.10, it behaves normally there. Unfortunately I don't have any ARM systems to try it on.
Such a problem is unlikely to be related to the kernel anyway. I would suspect any C runtime libraries that are linked in, perhaps they are kernel version dependent. It would be good if you could give the details of your build so that people can check the libraries. Are you using GNU libc, or one of the lightweight replacements like uLibc or dietlibc?
OpenWRT uses uClibc 0.9.33.2 by default. Other choices are musl (0.9.8 or 0.9.9) or eglibc (2.15, 2.16 or 2.17). I will try each one of them and let you know.
I've got exact the same problem.
Like Anton said: The connection reset occurs in about 75% of all print jobs.
I'm using Windows 7 x64 and Windows XP x64 on my PCs, WR1043nd router with OpenWrt AA 12.09-rc1 and HP DJ3940 printer.
kmod-usb-printer 3.3.8-1
p910nd 0.95-2
Problem occurs only on Windows 7 device.
More information will help. If you could provide wireshark dumps of a successful print job and an unsuccessful print job and upload them to this sourceforge site as an attachment to this ticket, somebody may be able to get more clues from it. It may be some kind of protocol problem that happens only with Windows 7. I am most likely unable to help since I have neither Windows 7 or a OpenWRT router.
BTW, is this connection using IP4 or IPv6?
Last edit: Anonymous 2014-01-07
Could somebody try the new 0.96 and see if the problem is still there? Thanks.
Successful printing job on winXP x32 Machne
And dump file of the Win7x64 - printing failed.
I've just added wireshark dump files to this ticket.
One mistake of mine is that my windows xp machine is x32 not x64 like i said before.
I'm using IPv4.
I can try 0.96 but i cant build package for OpenWRT AA for ar71xx. If you provide a link to the package i'm gonna check this on my router.
Please try 0.97; there have been more fixes.
Sorry, you'll have to pester downstream maintainers to build a package for your platform, as I don't maintain those.
Last edit: Anonymous 2014-01-16
After some days of debugging, I'm pretty sure that printing to a Standard TCP/IP Port (using RAW 9100 protocol) from Win7/x64 is broken in general! (probably on all x64 Versions of Windows??) I tested several Service Packs and Hotfixes.
On p910nd side, this results in a "copy_stream: Connection reset by peer" error in 75% of the job, as already reported by Lukas. On Windows client side, you will probably suffer 100% CPU usage and see an incomplete print job in the printer queue which cannot be cancelled.
The bugfixes I did in 0.96 and 0.97 will NOT fix this problems with Windows 7 x64 clients! Instead it will fix similar problems (incomplete printout) with clients like WinXP/32, Linux/CUPS, MacOSX/CUPS which I tested.
Sadly, imho, the only way to properly print to some network printer from Win7/x64 is currently by using IPP or SAMBA, thus you finally need a CUPS standalone server or CUPS/SAMBA server combination.
CUPS, of course, can in turn be used again as a client of p910nd, if the printer is not directly connected to the machine running CUPS.
Last edit: Stefan Sichler 2014-01-16
@Anton: which client did you use?
Are you sure the problem arose when upgrading the kernel version on th p910nd server? Did you also change the client system in the same timespan???