This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 335611 - ipp printer not working
ipp printer not working
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: system-config-printer (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-17 00:16 EDT by Rodd Clarkson
Modified: 2008-04-22 08:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-22 08:11:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
ipp.pcap output from `tcpdump -s0 -U -w ipp.pcap tcp port ipp` (24 bytes, application/octet-stream)
2008-04-05 19:11 EDT, Rodd Clarkson
no flags Details
output of 'tcpdump -ieth1 -s0 -U -w ipp.pcap tcp port ipp' (2.37 KB, application/octet-stream)
2008-04-14 22:24 EDT, Rodd Clarkson
no flags Details

  None (edit)
Description Rodd Clarkson 2007-10-17 00:16:11 EDT
Description of problem:

I have a Brother HL-5250DN Laser Printer which supports a number of different
printing protocols including LPD and IPP.  I'm able to print to this printer
using both these protocols under fedora 7, but using rawhide, LPD works but IPP
doesn't.



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

system-config-printer-0.7.74.4-3.fc8


How reproducible:

Very.



Steps to Reproduce:
1.  Change Device URI: to ipp://192.168.1.250/printers/P1 and print test page. 
This doesn't work.
2.  Change Device URI: to lpd://192.168.1.250/P1 and print test page.  This works.

  
Additional info:

Strangely, setting up a new printer used to autodetect this printer, but it no
longer does.

Looking at my firewall settings, both ipp (631/tcp; 631/udp) and mDNS (5353/udp)
are allowed, so I don't think this is firewall related.
Comment 1 Tim Waugh 2007-11-13 10:41:00 EST
I'd like some more information:

1. Please show me the output of 'rpm -q cups'.
2. I'd like to see the IPP traffic when sending a print job:
  Choose the ipp: Device URI.
  Run this as root: tcpdump -s0 -U -w ipp.pcap tcp port ipp
  then send a print job.  Attach the ipp.pcap file you get.

Thanks.
Comment 2 Bug Zapper 2008-04-04 10:08:53 EDT
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 3 Rodd Clarkson 2008-04-05 19:10:31 EDT
[rodd@localhost ~]$ rpm -q cups
cups-1.3.6-2.fc8



note that this seems to be listening to eth0 butI'm using eth1.


[root@localhost ~]# tcpdump -s0 -U -w ipp.pcap tcp port ipp
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes


0 packets captured
0 packets received by filter
0 packets dropped by kernel
Comment 4 Rodd Clarkson 2008-04-05 19:11:57 EDT
Created attachment 301401 [details]
ipp.pcap output from `tcpdump -s0 -U -w ipp.pcap tcp port ipp`
Comment 5 Tim Waugh 2008-04-14 11:28:34 EDT
In that case you need to use this command line:

tcpdump -ieth1 -s0 -U -w ipp.pcap tcp port ipp

(sorry!)
Comment 6 Rodd Clarkson 2008-04-14 22:24:15 EDT
Created attachment 302406 [details]
output of 'tcpdump -ieth1 -s0 -U -w ipp.pcap tcp port ipp'

[root@localhost ~]# tcpdump -ieth1 -s0 -U -w ipp.pcap tcp port ipp
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535
bytes
14 packets captured
14 packets received by filter
0 packets dropped by kernel
[root@localhost ~]# less ipp.pcap 
"ipp.pcap" may be a binary file.  See it anyway? 
[root@localhost ~]#
Comment 7 Tim Waugh 2008-04-15 03:00:50 EDT
Can you show me a tcpdump of the traffic between a Fedora 7 machine and the
printer, using IPP?  It seems like the IPP URI is just not recognized by the
printer.
Comment 8 Rodd Clarkson 2008-04-15 05:52:26 EDT
alright, for starters, this is a fedora 8 machine at this point.

Also, I'm not sure how to use tcpdump so a few pointers might speed things along.

Finally, what do you think that printer might expect.  At some stage, the
printer was detected by system-config-printer and I could just select it,
instead of having to set up the whole protocol thing.
Comment 9 Tim Waugh 2008-04-15 07:24:53 EDT
There is no way to know what IPP URI the printer might expect unless it tells us
using mDNS or SNMP (and here it seems it doesn't).

Just to try SNMP explicitly, what does this command say?:

  /usr/lib/cups/filter/snmp 192.168.1.250

(it might give no output, in which case there is no useful information for us.)

Can you try just using 'ipp://192.168.1.250/ipp'?

> Strangely, setting up a new printer used to autodetect this printer, but it no
> longer does.

Can you describe what you saw?  Did the printer automatically appear as a
separate entry in the same list as "Internet Printing Protocol (ipp)" or did you
need to select the IPP entry?  Was the hostname already filled in or did you
need to supply it?
Comment 10 Rodd Clarkson 2008-04-16 06:22:39 EDT
(In reply to comment #9)
> There is no way to know what IPP URI the printer might expect unless it tells us
> using mDNS or SNMP (and here it seems it doesn't).
> 
> Just to try SNMP explicitly, what does this command say?:
> 
>   /usr/lib/cups/filter/snmp 192.168.1.250

Hmmm, I don't have snmp in that folder.

[rodd@localhost ~]$ ls /usr/lib/cups/filter/
commandtoescpx  imagetops      pstopxl        rastertohp     texttops
commandtopclx   imagetoraster  pstoraster     rastertolabel
foomatic-rip    pdftops        rastertodymo   rastertopclx
gziptoany       pstopdf        rastertoepson  textonly
hpgltops        pstops         rastertoescpx  texttopaps

 
> (it might give no output, in which case there is no useful information for us.)
> 
> Can you try just using 'ipp://192.168.1.250/ipp'?

Tried this and it works.  Hmmm

> > Strangely, setting up a new printer used to autodetect this printer, but it no
> > longer does.
> 
> Can you describe what you saw?  Did the printer automatically appear as a
> separate entry in the same list as "Internet Printing Protocol (ipp)" or did you
> need to select the IPP entry?  Was the hostname already filled in or did you
> need to supply it?

From memory, I did add new printer and in list of devices my printer was
displayed as a choice at the top of the list (above Windows Printer via SAMBA).
 I didn't have to do anything other than select it.

I'm not aware of having changed any settings on the actual printer that might
have stopped it broadcasting this information.

Comment 11 Tim Waugh 2008-04-17 06:36:56 EDT
Sorry, I got the wrong directory name.  Try this:

  CUPS_DEBUG_LEVEL=1 /usr/lib/cups/backend/snmp 192.168.1.250
Comment 12 Rodd Clarkson 2008-04-17 07:16:26 EDT
[rodd@localhost ~]$ CUPS_DEBUG_LEVEL=1 /usr/lib/cups/backend/snmp 192.168.1.250
INFO: Using default SNMP Community public
DEBUG: Scanning for devices in "public" via "192.168.1.250"...
DEBUG: 0.000 Sending 46 bytes to 192.168.1.250...
DEBUG: 0.009 Received 55 bytes from 192.168.1.250...
DEBUG: community="public"
DEBUG: request-id=1208430660
DEBUG: error-status=0
DEBUG: add_cache(addr=0xbfca3c38, addrname="192.168.1.250", uri="(null)",
id="(null)", make_and_model="(null)")
DEBUG: 0.009 Sending 46 bytes to 192.168.1.250...
DEBUG: 0.077 Received 70 bytes from 192.168.1.250...
DEBUG: community="public"
DEBUG: request-id=1208430661
DEBUG: error-status=0
DEBUG: 1.076 Probing 192.168.1.250...
DEBUG: 1.076 Trying socket://192.168.1.250:9100...
DEBUG: 192.168.1.250 supports AppSocket!
network socket://192.168.1.250 "Brother HL-5250DN series" "Brother HL-5250DN
series 192.168.1.250" ""
DEBUG: 1.089 Scan complete!
[rodd@localhost ~]$ 
Comment 13 Tim Waugh 2008-04-17 07:44:32 EDT
OK, so that's working when we call it directly.  What does:

  /usr/sbin/lpinfo -l -v

say for the 'Device: uri = socket://192.168.1.250'... section?
Comment 14 Rodd Clarkson 2008-04-17 18:59:42 EDT
Here's the output.  No mention of 192.168.1.250 :-[

[rodd@localhost ~]$ /usr/sbin/lpinfo -l -v
Device: uri = socket
        class = network
        info = AppSocket/HP JetDirect
        make-and-model = Unknown
        device-id = 
Device: uri = beh
        class = network
        info = Backend Error Handler
        make-and-model = Unknown
        device-id = 
Device: uri = hal
        class = direct
        info = Hal printing backend
        make-and-model = Unknown
        device-id = 
Device: uri = hpfax
        class = direct
        info = HP Fax (HPLIP)
        make-and-model = Unknown
        device-id = 
Device: uri = hp
        class = direct
        info = HP Printer (HPLIP)
        make-and-model = Unknown
        device-id = 
Device: uri = http
        class = network
        info = Internet Printing Protocol (http)
        make-and-model = Unknown
        device-id = 
Device: uri = ipp
        class = network
        info = Internet Printing Protocol (ipp)
        make-and-model = Unknown
        device-id = 
Device: uri = lpd
        class = network
        info = LPD/LPR Host or Printer
        make-and-model = Unknown
        device-id = 
Device: uri = scsi
        class = direct
        info = SCSI Printer
        make-and-model = Unknown
        device-id = 
Device: uri = smb
        class = network
        info = Windows Printer via SAMBA
        make-and-model = Unknown
        device-id = 
[rodd@localhost ~]$ 
Comment 15 Tim Waugh 2008-04-18 07:16:17 EDT
You probably need to adjust /etc/cups/snmp.conf and uncomment 'Address @LOCAL'.
Comment 16 Rodd Clarkson 2008-04-20 20:10:24 EDT
[rodd@localhost ~]$ cat /etc/cups/snmp.conf 
Address @LOCAL
#Community public
#DebugLevel 0
#HostNameLookups off
[rodd@localhost ~]$ 

Still not seeing any reference to 192.168.1.250
Comment 17 Tim Waugh 2008-04-21 10:58:02 EDT
What does this say?:

CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp @LOCAL
Comment 18 Rodd Clarkson 2008-04-22 05:40:17 EDT
[rodd@localhost ~]$ sudo CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp @LOCAL
[sudo] password for rodd: 
INFO: Using default SNMP Community public
DEBUG: Scanning for devices in "public" via "@LOCAL"...
DEBUG: 0.000 Sending 46 bytes to 192.168.1.255...
DEBUG: SEQUENCE 44 bytes
DEBUG:     INTEGER 1 bytes 0
DEBUG:     OCTET STRING 6 bytes "public"
DEBUG:     Get-Request-PDU 31 bytes
DEBUG:         INTEGER 4 bytes 1208856852
DEBUG:         INTEGER 1 bytes 0
DEBUG:         INTEGER 1 bytes 0
DEBUG:         SEQUENCE 17 bytes
DEBUG:             SEQUENCE 15 bytes
DEBUG:                 OID 11 bytes .1.3.6.1.2.1.25.3.2.1.2.1
DEBUG:                 NULL VALUE 0 bytes
DEBUG: 1.002 Scan complete!
[rodd@localhost ~]$ 
Comment 19 Tim Waugh 2008-04-22 05:49:39 EDT
Seems this device doesn't respond to SNMP broadcast queries.  There's nothing we
can do about that really.

What about when you run '/usr/lib/cups/backend/dnssd'?
Comment 20 Rodd Clarkson 2008-04-22 05:58:40 EDT
[rodd@localhost ~]$ /usr/lib/cups/backend/dnssd
[rodd@localhost ~]$ 
Comment 21 Tim Waugh 2008-04-22 06:20:53 EDT
The only other network-type scan for printers in Fedora is for HP printers
(using HPLIP), so I'm not sure how it worked for you in Fedora 7. :-/

About the only other suggestion I have for you is to temporarily disable the
firewall and see if that makes any difference.
Comment 22 Rodd Clarkson 2008-04-22 08:11:24 EDT
Tim, thanks for all your help on this.  I guess where not going to get anywhere
with this, so I'll close it and open it again if I think it worth while.

I really appreciate your quick responses and you helpful hand holding.  It's a
bugger we couldn't resolve this.
Comment 23 Tim Waugh 2008-04-22 08:17:46 EDT
OK, thanks.  Yes, it's a pity we couldn't get to the bottom of it.  Please
re-open if you make any further discoveries.

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