Description of problem: My HP Officejet 6500, connected to the home LAN, works fine up to Fedora 17, but in Fedora 18, scanning for it (with iptables disabled to make sure) shows no device detected Version-Release number of selected component (if applicable): hplip-3.12.10-4.a.fc18.x86_64 hpijs-3.12.10-4.a.fc18.x86_64 dbus-libs-1.6.8-2.fc18.x86_64 dbus-python-1.1.1-1.fc18.x86_64 cups-libs-1.5.4-14.fc18.x86_64 In case hplip uses them: avahi-0.6.31-6.fc18.x86_64 nss-mdns-0.10-11.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. hp-setup 2. Select Network/Ethernet/Wireless network 3. Next Actual results: Searching... (bus=net, timeout=5, ttl=4, search=(None) desc=0, method=mdns) error: No devices found on bus: net Expected results: Device found Additional info: Does hplip depend on nss-mdns, or Avahi? It does not directly depend on either of them
(In reply to comment #0) > but in Fedora 18, scanning for it (with iptables disabled to make sure) The default 'firewall' service in F18 is no longer iptables service but firewalld service. Have you tried also 'service firewalld stop' ? > hplip-3.12.10-4.a.fc18.x86_64 You could also try 3.12.11 from updates-testing: yum --enablerepo=updates-testing update hplip
(In reply to comment #0) > Does hplip depend on nss-mdns, or Avahi? It does not directly depend on > either of them No. It has its own independent implementation unfortunately.
Ah, yes, stopping firewalld temporarily works. I forgot about it since firewalld was also slated to be the default in F17 and then backed out; apologies. Opening port 5353/udp (as mentioned, for example here -- https://bugzilla.redhat.com/show_bug.cgi?id=214058 -- that bug report is still open!) does not seem to help. While avahi-discover finds the printer just fine without having to tinker with the firewall (mdns is set to be trusted by default). Is there an upstream bug report for this? Surely upstream needs to know it's a bad idea for everyone to have to either disable their firewalls when configuring their printers -- or using another tool to discover its IP address first, and then spoon-feeding it to hp-setup.
We should presumably collapse all hp-setup mdns related bugs into one as well - feel free to make this a dupe of #214058
Ah, yes, I think you're right: this is a duplicate. This kind of bug, involving firewall infrastructure, is tricky to deal with upstream... really it needs to be analysed as part of system integration i.e. the various OS vendors (in this case Fedora). *** This bug has been marked as a duplicate of bug 214058 ***