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:
My hope was that this was related to bug #233747, but that appears to not be the case.
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
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.
Me either. :-( Are you still using FC6?
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 :)
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
(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.
Please try the test update: yum --enablerepo=updates-testing update 'hplip*' 'hpijs*' 'libsane-hpaio*' Does this problem persist?
Yes, it is still happening.
Can you run; su -c "netstat -pa | grep 2207" and send that output? A
# netstat -pa | grep 2207 tcp 0 0 snowflake.local:2207 *:* LISTEN 15180/python
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.
Created attachment 158911 [details] /etc/sysconfig/iptables
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.
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.
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
Updated to Fedora-8 release. I'll confirm with Fedora-9 soon too.
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
"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.
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.
# 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?
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.
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?
(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.
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
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
*** Bug 883619 has been marked as a duplicate of this bug. ***
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.
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.