Bug 214058 - hplip: hp-setup mdns and slp queries fail with iptables active
hplip: hp-setup mdns and slp queries fail with iptables active
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: system-config-firewall (Show other bugs)
17
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
: Triaged
: 883619 (view as bug list)
Depends On:
Blocks: F7Update
  Show dependency treegraph
 
Reported: 2006-11-05 03:46 EST by Bernard Johnson
Modified: 2013-08-01 14:21 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 14:21:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
wireshark capture (537 bytes, application/octet-stream)
2007-03-29 18:34 EDT, Bernard Johnson
no flags Details
/etc/sysconfig/iptables (949 bytes, text/plain)
2007-07-10 18:41 EDT, Bernard Johnson
no flags Details

  None (edit)
Description Bernard Johnson 2006-11-05 03:46:32 EST
Description of problem:
Running hp-setup in GUI mode fails to detect the printer.  Running "hp-setup -i
w.x.y.z" detects the printer and is able to configure it.

Version-Release number of selected component (if applicable):
hplip-1.6.10-1.fc6.4

How reproducible:
Always

Steps to Reproduce:
1. hp-setup w.x.y.z
2.
3.
  
Actual results:
(this is the text output when running the gui)
# hp-setup 192.168.1.x

HP Linux Imaging and Printing System (ver. 1.6.10)
Printer/Fax Setup Utility ver. 3.1

Copyright (c) 2003-6 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

0
error: <b>No devices found.</b><p>Please make sure your printer is properly
connected and powered-on.
Done.

Expected results:
If the interactive hplip succeeds, then the gui should as well.

Additional info:
Comment 1 Bernard Johnson 2007-03-29 14:51:39 EDT
My hope was that this was related to bug #233747, but that appears to not be the
case.
Comment 2 Bernard Johnson 2007-03-29 18:34:40 EDT
Created attachment 151243 [details]
wireshark capture

Ok, as it turns out, this is because hp-setup uses multicast to detect the
local devices.	It sends out the multicast packet, but the firewall drops it.

If I add:

-A RH-Firewall-1-INPUT -p udp --sport 427 -j ACCEPT

427 = server location protocol

to the iptables configuration the multicast discovery works correctly.	I don't
like the --sport option though, as it seems fairly dangerous for a firewall
setting.  I'm sure there is a better way, but this is the extent of my iptables
fu.

I should also point out that this appears to have nothing to do with gui vs.
text mode operation.

The text mode setup worked before because I gave it the IP address of the
printer on the command line and it didn't do a discovery.

Running the equivalent of what the gui runs for discovery ('hp-probe -bnet'),
shows that the multicast discovery fails in text mode as well.

Attached is a wireshark capture of the the two packets: 1) SRVLOC attribute
request and 2) SRVLOC attribute reply
Comment 3 Bernard Johnson 2007-04-03 14:03:04 EDT
So, in *my* mind it's clear that I shouldn't *have* to be mucking with the
firewall (this should be allowed as RELATED traffic right?), but it seems that
something odd is going on.  hp-setup has the ability to use slp or mdns for
discovery.  I switched to testing with mdns so that I could test the results and
packets against avahi-discover.

Here is what I get when I run avahi-discover | grep -i 2236D2
Found service 'HP Color LaserJet 2840 (2236D2)' of type '_printer._tcp' in
domain 'local' on 2.0.
Found service 'HP Color LaserJet 2840 (2236D2)' of type '_pdl-datastream._tcp'
in domain 'local' on 2.0.
Found service 'HP Color LaserJet 2840 (2236D2)' of type '_http._tcp' in domain
'local' on 2.0.

Ok, that looks good.  Now when I run:
hp-probe -mmdns -bnet

HP Linux Imaging and Printing System (ver. 1.6.12)
Printer Discovery Utility ver. 3.1

Copyright (c) 2003-6 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Probing network for printers. Please wait, this will take approx. 10 seconds...

warning: No devices found on the 'net' bus. If this isn't the result you are
expecting,
warning: check your network connections and make sure your internet
warning: firewall software is disabled.

One thing i noticed with wireshark is that avahi-discover sends packets with a
source port of 5353, which hp-probe does not.  If I bind hp-probe mdns to 5353
for source port, the results do not change EXCEPT...

Once I do a discovery with hp-probe on source port 5353, subsequent
avahi-discovery tests will not find the PDL resource:

avahi-discover | grep -i 2236D2
Found service 'HP Color LaserJet 2840 (2236D2)' of type '_printer._tcp' in
domain 'local' on 2.0.
Found service 'HP Color LaserJet 2840 (2236D2)' of type '_http._tcp' in domain
'local' on 2.0.

If I drop the firewall and run avahi-discover once, then restart the firewall,
it can see the pdl resource again.

Not sure what to make of all this.
Comment 4 Tim Waugh 2007-06-13 12:50:53 EDT
Me either. :-(

Are you still using FC6?
Comment 5 Bernard Johnson 2007-06-14 12:02:32 EDT
I'm running F7 now with the same results.  

> If I drop the firewall and run avahi-discover once, then restart the firewall,
> it can see the pdl resource again.

Maybe reassign it to iptables component and let them explain why packets are
sometimes being blocked :)
Comment 6 Tim Waugh 2007-06-14 12:27:34 EDT
I'd like to get you to try HPLIP 1.7.4a.  I've built a package, but due to an
infrastructure issue (https://hosted.fedoraproject.org/projects/bodhi/ticket/58)
I can't put it in the current test update at the moment.

In the mean time, you could try downloading the RPM packages (1.7.4a-2.fc7)
directly from here:
  http://koji.fedoraproject.org/koji/buildinfo?buildID=8797
Comment 7 Bernard Johnson 2007-06-14 14:01:16 EDT
(In reply to comment #6)
> In the mean time, you could try downloading the RPM packages (1.7.4a-2.fc7)
> directly from here:
>   http://koji.fedoraproject.org/koji/buildinfo?buildID=8797

The behavior seems to be identical.

Here is some more debugging information (starting with firewall on):

# hp-probe -mmdns -bnet -ldebug

HP Linux Imaging and Printing System (ver. 1.7.4a)
Printer Discovery Utility ver. 3.2

Copyright (c) 2001-7 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Probing network for printers. Please wait, this will take approx. 10 seconds...

hp-probe[21864]: debug: Outgoing: (44)
hp-probe[21864]: debug: 0000:  00 00 00 00 00 01 00 00 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21864]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21864]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01             
p.local.....:
hp-probe[21864]: debug: Outgoing: (44)
hp-probe[21864]: debug: 0000:  00 00 00 00 00 01 00 00 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21864]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21864]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01             
p.local.....:
hp-probe[21864]: debug: Outgoing: (44)
hp-probe[21864]: debug: 0000:  00 00 00 00 00 01 00 00 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21864]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21864]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01             
p.local.....:
hp-probe[21864]: debug: Outgoing: (44)
hp-probe[21864]: debug: 0000:  00 00 00 00 00 01 00 00 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21864]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21864]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01             
p.local.....:
hp-probe[21864]: debug: Found 0 devices
warning: No devices found on the 'net' bus. If this isn't the result you are
expecting,
warning: check your network connections and make sure your internet
warning: firewall software is disabled.

(note that there are no incoming packets)

# service iptables stop
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]

# hp-probe -mmdns -bnet -ldebug

HP Linux Imaging and Printing System (ver. 1.7.4a)
Printer Discovery Utility ver. 3.2

Copyright (c) 2001-7 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Probing network for printers. Please wait, this will take approx. 10 seconds...

hp-probe[21990]: debug: Outgoing: (44)
hp-probe[21990]: debug: 0000:  00 00 00 00 00 01 00 00 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21990]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21990]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01             
p.local.....:
hp-probe[21990]: debug: Incoming: (301)
hp-probe[21990]: debug: 0000:  00 00 84 00 00 01 00 01 00 00 00 03 0f 5f 70 64 
............._pd:
hp-probe[21990]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21990]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01 c0 0c 00 0c 
p.local.........:
hp-probe[21990]: debug: 0030:  00 01 00 00 00 0a 00 22 1f 48 50 20 43 6f 6c 6f 
.......".HP Colo:
hp-probe[21990]: debug: 0040:  72 20 4c 61 73 65 72 4a 65 74 20 32 38 34 30 20 
r LaserJet 2840 :
hp-probe[21990]: debug: 0050:  28 32 32 33 36 44 32 29 c0 0c c0 38 00 21 00 01 
(2236D2)...8.!..:
hp-probe[21990]: debug: 0060:  00 00 00 0a 00 12 00 00 00 00 23 8c 09 4e 50 49 
..........#..NPI:
hp-probe[21990]: debug: 0070:  32 32 33 36 44 32 c0 21 c0 38 00 10 00 01 00 00 
2236D2.!.8......:
hp-probe[21990]: debug: 0080:  00 0a 00 99 09 74 78 74 76 65 72 73 3d 31 08 71 
.....txtvers=1.q:
hp-probe[21990]: debug: 0090:  74 6f 74 61 6c 3d 31 19 74 79 3d 48 50 20 43 6f 
total=1.ty=HP Co:
hp-probe[21990]: debug: 00a0:  6c 6f 72 20 4c 61 73 65 72 4a 65 74 20 32 38 34 
lor LaserJet 284:
hp-probe[21990]: debug: 00b0:  30 20 70 72 6f 64 75 63 74 3d 28 48 50 20 43 6f 
0 product=(HP Co:
hp-probe[21990]: debug: 00c0:  6c 6f 72 20 4c 61 73 65 72 4a 65 74 20 32 38 34 
lor LaserJet 284:
hp-probe[21990]: debug: 00d0:  30 29 0b 70 72 69 6f 72 69 74 79 3d 34 30 20 61 
0).priority=40 a:
hp-probe[21990]: debug: 00e0:  64 6d 69 6e 75 72 6c 3d 68 74 74 70 3a 2f 2f 4e 
dminurl=http://N:
hp-probe[21990]: debug: 00f0:  50 49 32 32 33 36 44 32 2e 6c 6f 63 61 6c 2e 0d 
PI2236D2.local..:
hp-probe[21990]: debug: 0100:  54 72 61 6e 73 70 61 72 65 6e 74 3d 54 08 42 69 
Transparent=T.Bi:
hp-probe[21990]: debug: 0110:  6e 61 72 79 3d 54 06 54 42 43 50 3d 54 c0 6c 00 
nary=T.TBCP=T.l.:
hp-probe[21990]: debug: 0120:  01 00 01 00 00 00 0a 00 04 c0 a8 01 0b          
.............:
hp-probe[21990]: debug: Response: ID=0 FLAGS=0x8400 Q=1 A=1 AUTH=0 ADD=3
hp-probe[21990]: debug: Q: _pdl-datastream._tcp.local. TYPE=12 CLASS=1
hp-probe[21990]: debug: PTR: HP Color LaserJet 2840
(2236D2)._pdl-datastream._tcp.local.
hp-probe[21990]: debug: SRV: NPI2236D2.local. TTL=18 PRI=0 WT=0 PORT=9100
hp-probe[21990]: debug: TXT: {'Binary': 'T', 'product': '(HP Color LaserJet
2840)', 'ty': 'HP Color LaserJet 2840', 'adminurl': 'http://NPI2236D2.local.',
'qtotal': '1', 'priority': '40', 'txtvers': '1', 'Transparent': 'T', 'TBCP': 'T'}
hp-probe[21990]: debug: A: 192.168.1.11
hp-probe[21990]: debug: Outgoing: (90)
hp-probe[21990]: debug: 0000:  00 00 00 00 00 01 00 01 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21990]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21990]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01 c0 0c 00 0c 
p.local.........:
hp-probe[21990]: debug: 0030:  00 01 00 00 ff ff 00 22 1f 48 50 20 43 6f 6c 6f 
.......".HP Colo:
hp-probe[21990]: debug: 0040:  72 20 4c 61 73 65 72 4a 65 74 20 32 38 34 30 20 
r LaserJet 2840 :
hp-probe[21990]: debug: 0050:  28 32 32 33 36 44 32 29 c0 0c                   
(2236D2)..:
hp-probe[21990]: debug: Outgoing: (90)
hp-probe[21990]: debug: 0000:  00 00 00 00 00 01 00 01 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21990]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21990]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01 c0 0c 00 0c 
p.local.........:
hp-probe[21990]: debug: 0030:  00 01 00 00 ff ff 00 22 1f 48 50 20 43 6f 6c 6f 
.......".HP Colo:
hp-probe[21990]: debug: 0040:  72 20 4c 61 73 65 72 4a 65 74 20 32 38 34 30 20 
r LaserJet 2840 :
hp-probe[21990]: debug: 0050:  28 32 32 33 36 44 32 29 c0 0c                   
(2236D2)..:
hp-probe[21990]: debug: Outgoing: (90)
hp-probe[21990]: debug: 0000:  00 00 00 00 00 01 00 01 00 00 00 00 0f 5f 70 64 
............._pd:
hp-probe[21990]: debug: 0010:  6c 2d 64 61 74 61 73 74 72 65 61 6d 04 5f 74 63 
l-datastream._tc:
hp-probe[21990]: debug: 0020:  70 05 6c 6f 63 61 6c 00 00 0c 00 01 c0 0c 00 0c 
p.local.........:
hp-probe[21990]: debug: 0030:  00 01 00 00 ff ff 00 22 1f 48 50 20 43 6f 6c 6f 
.......".HP Colo:
hp-probe[21990]: debug: 0040:  72 20 4c 61 73 65 72 4a 65 74 20 32 38 34 30 20 
r LaserJet 2840 :
hp-probe[21990]: debug: 0050:  28 32 32 33 36 44 32 29 c0 0c                   
(2236D2)..:
hp-probe[21990]: debug: Found 1 devices
hp-probe[21990]: debug: Cache miss: hp_color_laserjet_2840
hp-probe[21990]: debug: Reading file: /usr/share/hplip/data/models/models.dat
hp-probe[21990]: debug: Searching for section [hp_color_laserjet_2840] in file
/usr/share/hplip/data/models/models.dat
hp-probe[21990]: debug: Found section [hp_color_laserjet_2840] in file
/usr/share/hplip/data/models/models.dat
  Device URI                                      Model                   Name     
  ----------------------------------------------  ----------------------  ---------
  hp:/net/HP_Color_LaserJet_2840?ip=192.168.1.11  HP_Color_LaserJet_2840  NPI2236D2

Found 1 printer(s) on the 'net' bus.


Comment 8 Tim Waugh 2007-07-02 08:55:41 EDT
Please try the test update:

  yum --enablerepo=updates-testing update 'hplip*' 'hpijs*' 'libsane-hpaio*'

Does this problem persist?
Comment 9 Bernard Johnson 2007-07-04 15:37:53 EDT
Yes, it is still happening.
Comment 10 Aaron Albright 2007-07-10 17:04:48 EDT
Can you run; su -c "netstat -pa | grep 2207"

and send that output?

A
Comment 11 Bernard Johnson 2007-07-10 17:17:45 EDT
# netstat -pa | grep 2207
tcp        0      0 snowflake.local:2207        *:*                        
LISTEN      15180/python
Comment 12 Bernard Johnson 2007-07-10 18:38:26 EDT
Tim,

Aaron and I have been talking offline and he's been able to replicate the
hp-probe simple test case.  We are both thinking that it's somehow related to
iptables (on and it doesn't work, off and it does work).  I think neither of us
is an expert in iptables though to know if the configuration is valid for what
we're trying to do.

My thinking is that the default RELATED line should allow this traffic, but I
don't know for sure.

Can you get someone from iptables involved in this (reassign?) to help debug a
little?  Thanks.
Comment 13 Bernard Johnson 2007-07-10 18:41:22 EDT
Created attachment 158911 [details]
/etc/sysconfig/iptables
Comment 14 Thomas Woerner 2008-01-10 09:13:11 EST
Please add this to your firewall configuration and try again:

-A RH-Firewall-1-INPUT -p udp --dport 427 -d 224.0.1.60 -j ACCEPT

This should work without mdns.
Comment 15 Bernard Johnson 2008-01-23 21:29:47 EST
No, that doesn't work.

Please look at the wireshark capture I made in comment #2.  The printer doesn't
do a SLP reply to 224.0.1.60, it replies to the IP address of the system that
sent the location request.  And not to port 427.
Comment 16 Bug Zapper 2008-05-14 08:04:36 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bernard Johnson 2008-05-18 21:02:57 EDT
Updated to Fedora-8 release.  I'll confirm with Fedora-9 soon too.
Comment 18 Bug Zapper 2008-11-25 20:51:08 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Andrew Malcolmson 2008-12-28 19:43:33 EST
"hp-probe -bnet -mmdns" locates my networked Photosmart 2575 from Debian Etch running hplip 2.8.6 after tweaking my iptables rules to allow UDP packets:

1) from my local machine to the LAN to destination port 5353
2) from the LAN to my local machine from source port 5353

In Shorewall's rules file this was:

ACCEPT      $FW     lan udp 5353
ACCEPT      lan     $FW udp -   5353

Hope this helps.
Comment 20 Thomas Woerner 2009-06-03 05:02:01 EDT
Can you please add the output of iptables-save? What is $FW here? And please add a log of the connection to the printer.

Reassigning to system-config-firewall.
Comment 21 Bernard Johnson 2009-06-04 22:21:38 EDT
# iptables-save
# Generated by iptables-save v1.4.1.1 on Thu Jun  4 20:18:18 2009
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1595:226721]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -d 224.0.0.251/32 -p udp -m state --state NEW -m udp --dport 5353 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 137 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 138 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 49200 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Thu Jun  4 20:18:18 2009


Did you need more than the wireshark capture I previously attached?
Comment 22 Bernard Johnson 2009-11-22 14:07:04 EST
In Fedora 12, the rule for mDNS is not sufficient.  It must be relaxed to this:

-A INPUT -m state --state NEW -m udp -p udp --sport 5353 -j ACCEPT

I can upload a wireshark capture of this if you're interested.
Comment 23 Thomas Woerner 2010-06-01 09:50:15 EDT
With this rule udp connections to all ports on the local machine are allowed as long as the source port is 5353. This is not a good idea in my opinion.

Are there any other ways to get this working?
Comment 24 Bernard Johnson 2010-11-01 00:50:53 EDT
(In reply to comment #23)
> With this rule udp connections to all ports on the local machine are allowed as
> long as the source port is 5353. This is not a good idea in my opinion.
> 
> Are there any other ways to get this working?

Not that I've been able to determine.
Comment 25 Bug Zapper 2010-11-04 08:14:45 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Yulia Kopkova 2010-11-04 09:03:41 EDT
Just tried on Fedora 14
hplip-3.10.9-2.fc14 can not discover HP Officejet Pro 8500 A909a printer
system-config-printer-1.2.5-6.fc14 find the printer
Comment 27 Tim Waugh 2012-12-10 07:43:04 EST
*** Bug 883619 has been marked as a duplicate of this bug. ***
Comment 28 Fedora End Of Life 2013-07-04 02:44:22 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 29 Fedora End Of Life 2013-08-01 14:21:59 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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