Results 1 to 4 of 4

Thread: Firewall configuration for HPLIP/hp-setup printer autodiscovery

  1. #1
    Join Date
    Jun 2020
    Posts
    23

    Default Firewall configuration for HPLIP/hp-setup printer autodiscovery

    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):

    Code:
    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:

    Code:
    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:

    Code:
    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:

    Code:
    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:

    Code:
    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:

    Code:
    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:

    Code:
    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:

    Code:
    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:

    Code:
    calypso:~ # systemctl daemon-reload
    calypso:~ # systemctl enable conntrackd.service
    After a reboot, you should be able to see the SLP helper and firewall rules:

    Code:
    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.

  2. #2
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    29,092
    Blog Entries
    15

    Default Re: Firewall configuration for HPLIP/hp-setup printer autodiscovery

    Hi
    After a peer review here, I would suggest it's better to put up on the openSUSE SDB Wiki....
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #3
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    26,699

    Default Re: Firewall configuration for HPLIP/hp-setup printer autodiscovery

    I followed the thread that lead to this Howto (well, did not read all of it). Did not understand everything, but I know a bit about avahi (enough to decide that I do not need it and thus switched it off).

    Now reading this, everything bcomes very clear to me. I understand the why, the how and all. I concur with Malcolm that this should be on a better place then here as an unreviewed Howto.
    Henk van Velden

  4. #4
    Join Date
    Jun 2020
    Posts
    23

    Default Re: Firewall configuration for HPLIP/hp-setup printer autodiscovery

    Quote Originally Posted by malcolmlewis View Post
    Hi
    After a peer review here, I would suggest it's better to put up on the openSUSE SDB Wiki....
    that's OK, I posted it here after deano_ferrari suggested it in the original thread

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •