Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 592698 - printer configuration seems ok but socket backend fails
Summary: printer configuration seems ok but socket backend fails
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-16 11:07 UTC by Nikolai Maziashvili
Modified: 2010-05-20 19:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-20 13:26:45 UTC
Type: ---

Attachments (Terms of Use)
cups_error_log (4.66 MB, text/plain)
2010-05-16 18:19 UTC, Nikolai Maziashvili
no flags Details
lpinfo output (1.83 KB, text/plain)
2010-05-16 18:19 UTC, Nikolai Maziashvili
no flags Details
printer driver in use (54 bytes, text/plain)
2010-05-16 18:20 UTC, Nikolai Maziashvili
no flags Details
tcp.log (2.89 KB, text/plain)
2010-05-19 06:30 UTC, Nikolai Maziashvili
no flags Details
tcpdump_wiredLaptop_wirelesPrinter (9.04 KB, text/plain)
2010-05-20 08:06 UTC, Nikolai Maziashvili
no flags Details
tcpdump_both_wired (1.12 KB, text/plain)
2010-05-20 09:30 UTC, Nikolai Maziashvili
no flags Details
tcpdump_success (25.26 KB, text/plain)
2010-05-20 12:50 UTC, Nikolai Maziashvili
no flags Details

Description Nikolai Maziashvili 2010-05-16 11:07:13 UTC
Description of problem:
Setting HP Officejet J6400 goes without a glitch. Printer is a network printer and it has been automatically fount by printing wizard. Drivers were installed correctly, CUPS looks ok.
When sending test page or any other job for a print - printer doesn't show any sign of life, while CUPS showing job added to the list, printer status in processing.
I can ping printer, CUPS sees printer, good drivers are loaded but there is still no printing.
I don't know where it goes wrong.
Please tell me what kind of information i can provide you with to get deeper insight into this problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install printer
2. sent job
Actual results:

Expected results:

Additional info:
after fresh install of F13 week ago i configured printer and it did print. Last print i made was Friday. I updated yesterday, as far as i could see only openoffice updates were installed nothing special. But today i can't print anymore

Comment 1 Tim Waugh 2010-05-16 12:12:57 UTC
Please take a look at this page which gives some ideas about how to find the problem, and what information we need in order to help diagnose it:


Comment 2 Nikolai Maziashvili 2010-05-16 18:17:09 UTC
(In reply to comment #1)
> Please take a look at this page which gives some ideas about how to find the
> problem, and what information we need in order to help diagnose it:
> https://fedoraproject.org/wiki/Printing/Debugging    

Hi Tim,

Thank you for directing me to page. I think i have gethered some information that could be useful to you.
First i have emptied cups error_log file, then i turned cups debugging on (level2). Afterwards i submitted job (tried to print out letter).
All ended by pop up window saying that print job didn't go well.
More technical information, i guess, you will find in attached files. Hopefully resolution comes quick. I use fedora for my business - printer bug means no printing for my business...(yes i know their is RH for that), but anyways....

Comment 3 Nikolai Maziashvili 2010-05-16 18:19:19 UTC
Created attachment 414394 [details]

Comment 4 Nikolai Maziashvili 2010-05-16 18:19:56 UTC
Created attachment 414395 [details]
lpinfo output

Comment 5 Nikolai Maziashvili 2010-05-16 18:20:26 UTC
Created attachment 414396 [details]
printer driver in use

Comment 6 Tim Waugh 2010-05-18 11:52:18 UTC
Thanks for proving that information.

So first the dnssd backend get executed.  All that backend does is resolve the DNS-SD name and then execute whichever other backend can actually transfer the data to the device.  In this case it is the socket backend:

D [16/May/2010:19:30:14 +0200] [Job 21] Resolving "Officejet J6400 series [DF7CB5]", regtype="_pdl-datastream._tcp", domain="local."...
D [16/May/2010:19:30:14 +0200] [Job 21] Resolved as "socket://"...
D [16/May/2010:19:30:14 +0200] [Job 21] Executing backend "/usr/lib/cups/backend/socket"...

The socket backend manages to connect to the printer but some time later this connection fails:

E [16/May/2010:19:44:45 +0200] [Job 21] Unable to write print data: Broken pipe

(this comes from the write-data loop in backend/runloop.c)

So the question is: why did the TCP connection fail?

To know the answer I think we'll need to see what the TCP traffic actually looks like.  Please run this command as root:

tcpdump -l host | tee tcp.log

while sending the print job, and when it fails press Control-C to stop the tcpdump command.  Then please attach the tcp.log file to this bug report using the "Add an attachment" link above.

Comment 7 Nikolai Maziashvili 2010-05-19 06:29:15 UTC
Hi Tim,

I'm afraid i got just meaningless stuff here. Take a look at tcp.log in attachments.

Comment 8 Nikolai Maziashvili 2010-05-19 06:30:06 UTC
Created attachment 415029 [details]

Comment 9 Tim Waugh 2010-05-19 11:58:56 UTC
Did you run tcpdump on the CUPS server machine?

Maybe just run "tcpdump -n -l > tcp.log", or run wireshark.  I'm not sure why we aren't seeing any of the TCP connection at all.

Comment 10 Nikolai Maziashvili 2010-05-20 08:05:22 UTC
Hi Tim,

Of course i tcpdump on CUPS server machine :) .
First tcpdump that i posted was output of the following command:
tcpdump -i wlan0 -l host | tee tcp.log

My laptop, and printer as well, are wireless. Because whole tcpdump made not much sense i sought let me wire at last my laptop for now (easiest at this point) and try again.
I ran following command this time:
tcpdump -i eth0 -l host | tee tcp.log

and i got some what more information out of tcpdump. Please take a look.

This evening i want to try wire printer as well and try it again, see what happens.

Comment 11 Nikolai Maziashvili 2010-05-20 08:06:25 UTC
Created attachment 415338 [details]

Comment 12 Nikolai Maziashvili 2010-05-20 09:23:30 UTC
Ok...I have wired printer too. Very interesting development. When i try to print i get error: "There was a problem sending document 'blabla' (job 34)to the printer".
I click ok and window pops-up asking me if i want to diagnose the problem. I click yes and it comes up with answer: "The queue "HP-OfficeJet is not enabled the reason given is '/usr/lib/cups/backend/dnssd failed'" 
And it asks me to enable it from System-Administration-Printing menu. Which i do of course.
But when i try to print again is see in printer settings window that it gets disabled which results in the same error message all over again.
I did tcpdump of this communication but then again it is as useful as first one.

Comment 13 Nikolai Maziashvili 2010-05-20 09:30:18 UTC
Created attachment 415358 [details]

This time i wired them both. Although tcpdump still doesn't make a lot of sense.

Comment 14 Nikolai Maziashvili 2010-05-20 09:36:59 UTC
In the last tcpdump i see following line:
IP > ICMP host unreachable - admin prohibited,
length 96

I think this is the moment that i get asked to enable printer from settings
menu  ("polices" tab).
But it gets disabled as soon as i try to submit new print (job).

Comment 15 Tim Waugh 2010-05-20 10:16:02 UTC
Niko, we are not seeing the entire conversation in any of these traces.  The 'admin prohibited' message is just about an SNMP response, which is not required for being able to print -- but we don't see the corresponding query that the response is an answer to.

In your error_log in comment #3 we see this:

D [16/May/2010:19:30:14 +0200] [Job 21] Executing backend "/usr/lib/cups/backend/socket"...
D [16/May/2010:19:30:14 +0200] [Job 21] STATE: +connecting-to-device
D [16/May/2010:19:30:14 +0200] [Job 21] Looking up ""...
D [16/May/2010:19:30:14 +0200] [Job 21] Connecting to
I [16/May/2010:19:30:14 +0200] [Job 21] Connecting to printer...
D [16/May/2010:19:30:14 +0200] [Job 21] STATE: -connecting-to-device
I [16/May/2010:19:30:14 +0200] [Job 21] Connected to printer...
D [16/May/2010:19:30:14 +0200] [Job 21] Connected to (IPv4)...

which is a successful TCP connection to from your CUPS server (presumably  So when tracing it, we expect to see at least these packets: > SYN > SYN ACK > ACK

But they are not there. :-/  This is the connection we need to be able to watch.

Let's start at the beginning.  What do '/sbin/ifconfig' and '/sbin/route -n' say?

Comment 16 Nikolai Maziashvili 2010-05-20 11:24:38 UTC
Hi Tim,

I have switched wlan off and now laptop ( as well as printer ( are wired. So let's do this...

eth0      Link encap:Ethernet  HWaddr 00:24:BE:5A:9C:B2  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::224:beff:fe5a:9cb2/64 Scope:Link
          RX packets:627 errors:0 dropped:0 overruns:0 frame:0
          TX packets:729 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:347429 (339.2 KiB)  TX bytes:138135 (134.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:480 (480.0 b)  TX bytes:480 (480.0 b)

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     1      0        0 eth0         UG    0      0        0 eth0

Comment 17 Nikolai Maziashvili 2010-05-20 11:30:05 UTC
Forgot to add, to avoid confusion... was printer when it was hooked up to wlan. But now wired nic got ip addr.
And is my laptop (wired nic).

Comment 18 Nikolai Maziashvili 2010-05-20 12:46:59 UTC
OK.... this is what happened.
I deleted printer, restarted cups added printer again, but now beeing connected through wire. In the end of "printer adding" wizard i was asked to print a test page. i ran tcpdump command (just in case) and WHOILLA - test page is printed.

I'm attaching new tcpdump here take a look, all those SIN ACk you have mentioned are there, well obviously - page was printed right?

So next what i'm gonna do is set printer up again but only with wireless to see if it goes wrong again.
If it does then there is something wrong with wireless communication between cups and printer.

Comment 19 Nikolai Maziashvili 2010-05-20 12:50:07 UTC
Created attachment 415403 [details]

this time printer was set up from scratch.
I connected printer and laptop to the network through wire. Deleted printer from laptop, added it again with wizard tool from System-Administration-Printing menu. 
And it worked!!!

Next step is to repeat all this but with wireless setup. Please Tim take a look at tcpdump just to make sure that it looks ok.

Comment 21 Tim Waugh 2010-05-20 13:26:45 UTC
(In reply to comment #17)
> Forgot to add, to avoid confusion... was printer when it was hooked up
> to wlan. But now wired nic got ip addr.
> And is my laptop (wired nic).    

OK, I think your problem is that your wired and wireless network share the same subnet address.  They need to use separate subnets, e.g. and

Comment 22 Nikolai Maziashvili 2010-05-20 19:18:42 UTC
(In reply to comment #21)
> (In reply to comment #17)
> > Forgot to add, to avoid confusion... was printer when it was hooked up
> > to wlan. But now wired nic got ip addr.
> > And is my laptop (wired nic).    
> OK, I think your problem is that your wired and wireless network share the same
> subnet address.  They need to use separate subnets, e.g. and    

I think i will disagree with you on that one. Only reason why i would separate the subnets is if i would run different DHCP severs for wired and wireless networks. I don't, my wireless router has no dhcp running, i just wanted my wireless router to be bridged to my wired router.

And after todays kernel update printer works again in wired as well as in wireless connections.
I'm very convinced (after todays update that it was some kernel related issue. Because when i fresh installed F13 beta printing worked very well. Then updates came in (kernel updates too of course and printing broke down. Todays kernel update seems to fixed this problem.
So leaving this "notabuganymore" closed. 

I would love to know what was the real reason for it not working, just for saik of learning but....everything is working now and i will not waist you time any more. 
Thanx for you input Tim.

Note You need to log in before you can comment on or make changes to this bug.