Problem
Automatic discovery of network printers fails to work with the firewall enabled.
For example, tools such as CUPS or the HP printer configuration tool hp-setup do not find devices on your network, unless you either disable the firewall or enter the device IP by hand.
Diagnosis
Printer discovery consists of two parts: locating the printer in the network, and locating services on the printer. There are different solutions for this. One of them is Zeroconf, which uses the multicast DNS (mDNS) protocol to discover devices; mDNS network communication takes place using UDP on port 5353. A free implementation of Zeroconf/Bonjour exists on Linux in the form of the Avahi software suite; it is used by CUPS and many other programs. Another approach is the Service Location Protocol (SLP), which uses UDP on port 427. These ports may be blocked by your firewall.
For many users, it will be enough to discover the printer in CUPS, which by default relies on Avahi.
A special problem exists for users who use the HPLIP software suite (and the hp-setup tool) for setting up HP printers over the network. HPLIP supports three autodiscovery methods: SLP (the default), mDNS through Avahi, and its own implementation of mDNS/Bonjour. For SLP and mDNS, it uses ephemeral UDP ports (short-lived ports that are assigned automatically). As a result, when the device responds to hp-setup’s requests, its UDP response packets go to this ephemeral port and get blocked by the firewall, even if the standard ports 427 and/or 5353 are open.
Workarounds
If you know the device’s IP address, you can avoid autodiscovery altogether and configure it by hand.
If your device happens to be HP printer, and you have a USB cable, you can attach the printer via USB, configure it using hp-setup, and it should then work over the network also after the USB network is disconnected.
There are some use cases where you know the device’s IP address, but need to use autodiscovery anyway. An example is trying to scan using VueScan with a network-attached HP multi-function printer; VueScan uses HPLIP, but does not offer manual IP addresses, only on-the-fly detection. In these cases you could open a firewall exception that allows inbound traffic from the printer’s IP address (as in this thread). Note that this can be dangerous if you then use this computer on other networks.
Solution
The solution has two parts.
(1) autodiscovery using Avahi (locating the printer through Zeroconf and the mDNS protocol)
(2) autodiscovery using hp-setup and its default SLP protocol, in case Avahi cannot be selected or is undesirable for some reason.
Part 1. Autodiscovery using Avahi (Zeroconf)
For many users it will be enough to get autodiscovery working in CUPS and other software that relies on Avahi. Avahi is a free Zeroconf/Bonjour implementation that facilitates service discovery and hostname resolution on a local network via the mDNS/DNS-SD protocol suite. However, on many systems the firewall is configured to block the UDP port 5353 that mDNS is using.
OpenSUSE uses firewalld, which provides a facility to allow mDNS communication by opening port 5353 for incoming UDP traffic. To activate this, find the firewall zone you’re in, and enable the mDNS service in this firewall zone.
You can use YAST for this, or you can use the command line, which would look like this (if you are in the “home” zone):
calypso:~ # firewall-cmd --zone=home --add-service=mdns
This should be enough to get it working. If the mdns service is enabled, the firewall configuration should look like this:
calypso:~ # firewall-cmd --list-all
home (active)
target: default
icmp-block-inversion: no
interfaces: wlan0
sources:
services: dhcpv6-client mdns ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
To check whether avahi is working, you can use avahi-browse (from the avahi-utils package) to show a list of all devices that are discoverable on your network:
calypso:~ # avahi-browse -at
+ wlan0 IPv4 calypso SSH Remote Terminal local
+ wlan0 IPv4 calypso SFTP File Transfer local
+ wlan0 IPv6 calypso SSH Remote Terminal local
+ wlan0 IPv6 calypso SFTP File Transfer local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] _privet._tcp local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] _privet._tcp local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] UNIX Printer local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] PDL Printer local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] Internet Printer local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] Web Site local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] _scanner._tcp local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] _http-alt._tcp local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] _uscan._tcp local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] Secure Internet Printer local
+ wlan0 IPv4 HP OfficeJet Pro 8710 [AD5ECE] _uscans._tcp local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] UNIX Printer local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] PDL Printer local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] Internet Printer local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] Web Site local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] _scanner._tcp local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] _http-alt._tcp local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] _uscan._tcp local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] Secure Internet Printer local
+ wlan0 IPv6 HP OfficeJet Pro 8710 [AD5ECE] _uscans._tcp local
This should be enough to make your printer appear.
If you use the HPLIP software suite to configure your printer, it supports Avahi as well, just not as a default method. When using hp-setup to set up the printer, choose “Network” under “Connection type”, then click on “Show Advanced Options”, and under “Network Discovery Method” select “Avahi”. Be careful not to choose “mDNS/Bonjour”, even though they use the same protocol. Your printer should appear.
If this is enough for you to start printing, you can stop here. Otherwise if for some reason you need to use HPLIP’s default discovery method SLP, continue to part 2.
**
Caveats
**Some users consider Zeroconf a security risk. This is because, as you can see in the output of avahi-browse -at above, by default Avahi announces itself on the network as well. This is how there you can see Avahi advertising my computer (calypso) and the SSH and SFTP services, so any user on that network would know that my computer exists and has an SSH server on it. Some users may find this behaviour undesirable. Others may find it convenient, because it allows things like using AirPrint on an iPad to locate a printer attached to your computer and print on it, or using iTunes or the Kodi media center to browse media sources in your local network.
If you find this behaviour undesirable, there are several ways go on about this this; only the first is in the scope of this tutorial:
- Enable the mDNS firewall exception only when you actually need to discover printers, and disable it right after.
- Avahi advertises those services for which a *.service file exists in /etc/avahi/services; you can make sure that only the services you want advertised are listed there.
- You can control Avahi’s publishing activity in the [publish] section of its configuration file /etc/avahi/avahi-daemon.conf; there are tutorials for this.
Part 2. Autodiscovery using SLP in hp-setup
If for some reason you need/want to use SLP as the discovery method, it gets a little more complicated. The OpenSUSE firewall also has a preconfigured SLP service rule to enable incoming UDP traffic on port 427. However, for HPLIP opening port 427 and enabling this exception is not sufficient. The problem is that hp-setup uses ephemeral ports, so we need to identify this SLP traffic and open temporary exceptions for the ports it’s coming from.
For this, we need to teach our firewall to recognize outgoing SLP packets from these ports and open exceptions on the fly. Our firewall has connection tracking built in, and connection tracking helpers for a number of protocols. However, there is no built-in helper for SLP. Luckily there exists the conntrack-tools package, which extends this kernel-level facility with a range of userspace connection tracking helpers, including one for SLP. These userspace helpers interface with the inbuilt firewall’s connection tracking through the conntrackd daemon. This is only a very small part of conntrackd’s capabilities; it is a powerful tool to build distributed firewalls and gather firewall usage statistics.
Step 2.1 Enabling SLP connection tracking
To enable connection tracking for SLP, install the conntrackd and conntrack-tools packages.
Edit the conntrackd configuration file (/etc/conntrackd/conntrackd.conf). It has a helpers section that is commented by default. Uncomment the section header, opening and closing braces, and the slp helper section within it:
Helper {
# Before this, you have to make sure you have registered the `ftp'
# user-space helper stub via:
#
# nfct add helper ftp inet tcp
#
# Type ftp inet tcp {
# #
...
# Type mdns inet udp {
# QueueNum 6
# QueueLen 10240
# Policy mdns {
# ExpectMax 8
# ExpectTimeout 30
# }
# }
Type slp inet udp {
QueueNum 7
QueueLen 10240
Policy slp {
ExpectMax 8
ExpectTimeout 16
}
}
}
After this, you need to manually enable the SLP connection helper (using nfct from the conntrack-tools package), and only then you can start up conntrackd:
calypso:~ # nfct add helper slp inet udp
calypso:~ # systemctl start conntrackd.service
By this moment, your firewall is capable of tracking SLP traffic, and we need to teach it to do so by adding firewall rules that tell it that an SLP connection begins by an outgoing multicast or broadcast UDP packet to port 427:
calypso:~ # firewall-cmd --direct --add-rule ipv4 raw OUTPUT 0\
-m addrtype --dst-type MULTICAST -p udp --dport 427 -j CT --helper slp
success
calypso:~ # firewall-cmd --direct --add-rule ipv4 raw OUTPUT 0\
-m addrtype --dst-type BROADCAST -p udp --dport 427 -j CT --helper slp
success
calypso:~ # firewall-cmd --direct --get-all-rules
ipv4 raw OUTPUT 0 -m addrtype --dst-type MULTICAST -p udp --dport 427 -j CT --helper slp
ipv4 raw OUTPUT 0 -m addrtype --dst-type BROADCAST -p udp --dport 427 -j CT --helper slp
At this moment hp-setup should be able to autodiscover your printer using SLP.
SLP does not have the same security considerations that we discussed earlier with Avahi. This is firstly because it is a less common protocol, for which users are unlikely to have a daemon running on their machine, and secondly because in our configuration we open the firewall only after a SLP connection has been initiated from inside. Still, you may need to see if you want to enable the SLP exception permanently, or only in one-off situations where you install and configure devices.
**Step 2.2 Making the changes permanent
**To get these changes to persist after boot, you’ll need to enable the conntrackd service, make sure that the SLP helper is added before conntrackd starts, and make sure that the firewall has the necessary rules to identify SLP traffic. First, take the firewall rules from step 2.1 and make them permanent:
calypso:~ # firewall-cmd --runtime-to-permanent
success
calypso:~ # firewall-cmd --reload
success
calypso:~ # firewall-cmd --direct --get-all-rules
ipv4 raw OUTPUT 0 -m addrtype --dst-type MULTICAST -p udp --dport 427 -j CT --helper slp
ipv4 raw OUTPUT 0 -m addrtype --dst-type BROADCAST -p udp --dport 427 -j CT --helper slp
The next problem is that we need to enable the conntrackd service at boot, but by default it does not load the SLP helpers. Also the firewall usually comes up before conntrackd, which means that the above two rules will fail to load because the SLP helper isn’t active yet. The easiest solution for both problems is to add a configuration drop-in to the conntrackd service which loads the SLP helper before conntrackd comes up, and reloads the firewall rules afterwards.
Create a file in /etc/systemd/system/conntrackd.service.d (by hand or using systemctl --edit conntrackd.service) that looks like this:
calypso:~ # cat /etc/systemd/system/conntrackd.service.d/nfct.conf
[Service]
ExecStartPre=-/usr/sbin/nfct add helper slp inet udp
ExecStartPost=/usr/bin/firewall-cmd --reload
Reload the changes to the systemd configuration and enable conntrackd service at boot:
calypso:~ # systemctl daemon-reload
calypso:~ # systemctl enable conntrackd.service
After a reboot, you should be able to see the SLP helper and firewall rules:
calypso:~ # nfct list helper
{
.name = slp,
.queuenum = 7,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 0,
.status = enabled,
};
calypso:~ # firewall-cmd --direct --get-all-rules
ipv4 raw OUTPUT 0 -m addrtype --dst-type MULTICAST -p udp --dport 427 -j CT --helper slp
ipv4 raw OUTPUT 0 -m addrtype --dst-type BROADCAST -p udp --dport 427 -j CT --helper slp
Now your system should be ready to use SLP autodiscovery also after a reboot.
