# Avoiding avahi

## miket

Some time ago I noticed a new feature creep into net-print/hplip:  an "oh so helpful" network-device-discovery service.  As a result, hplip started depending on net-dns/avahi.

When I read about it, I was Not Thrilled about what avahi does:  it is an implementation of mDNS, a service which happily makes a host respond to random other hosts on the LAN wanting to know that host's IP address.  When that host being queried is my laptop, which I often enough take into other people's networks, that kind of discoverability is not something I want.

Suffice it to say, but I No Not Want avahi.  As if I weren't already against installing it, I observe that its author also wrote certain (ahem) init and audio-transport systems.  I'll just be content discovering the IP addresses of printers on my own, thank you.

So now the problem.  When confronted with the avahi-using versions of hplip, I masked the newer hplip ebuilds to stick with version 3.20.6-r1.  That one has a hard dependency on automake 1.13, which is scheduled to go away.  This pushes me to update.

If I do an easy thing like fake out Portage by adding avahi to package.provided or set up a modified hplip ebuild in my local overlay, my bet is that hplip would fail to run--or even build--with avahi missing.  I suppose I could build avahi but not start the daemon, but then hplip might still complain.

I suspect that the hplip upstream went through a lot of effort to implement a much requested printer-discovery feature, so I'm doubtful they'd be fast to offer a way to circumvent it.  Is there a good way for me to avoid avahi and still use newer versions of hplip?  Am I going to end up needing to patch the hplip source?  Is there an avahi-faker I could use?  (This would never respond to queries on the network while consistently telling hplip that it finds no printers.)

----------

## dr_wulsen

I feel your frustration. I really dislike being forced to use "oh-so-futuristic-five-layers-abstracted-*kit" packages.

I prefer to rip out all stuff not necessary and run on the minimum required.

Workarounds:

German ubuntuusers wiki says:

 *Quote:*   

> Hat man keine Verwendung für Avahi, so kann man den Dienst deaktivieren. Dazu erstellt man eine Sicherungskopie der Datei /etc/init/avahi-daemon.conf und entfernt sie dann mit Root-Rechten.

 Which translates to:  *Quote:*   

> If you got no use for Avahi, you can disable the service. For that, create a backup copy of /etc/init.d/avahi-daemon.conf and remove the original afterwards.

 

You could (maybe, haven't tested) have the daemon running (bad enough) but just listening to no interface at all.

The avahi-daemon.conf manpage says:

use-ipv4= Takes a boolean value ("yes" or "no"). If set to "no" avahi-daemon will not use IPv4 sockets. Default is "yes".

use-ipv6= Takes a boolean value ("yes" or "no"). If set to "no" avahi-daemon will not use IPv6 sockets. Default is "yes".

allow-interfaces= Set a comma seperated list of allowed network interfaces that should be used by the avahi-daemon. Other interfaces will be ignored. If set to the empty list all local interfaces except loopback and point-to-point will be used.

deny-interfaces= Set a comma seperated list of network interfaces that should be ignored by avahi-daemon. Other not specified interfaces will be used, unless allow-interfaces is set. This option takes precedence over deny-interfaces.

So if you'd disallow IPv4 and IPv6, plus add everything to your deny-interfaces (does it accept a wildcard? I don't know) and only allow the loopback interface, it could be running but undetectable.

Of course, I'd prefer not having the package installed in the first place, but if that's not possible you could use those workarounds.

For the workaround(s) you can check 

```
sudo netstat -tulpen | grep avahi
```

to see if it's listening on any interface.

If it's only listening on localhost (127.0.0.1) I'd consider myself safe but still annoyed.

----------

## Goverp

I run hplip without avahi.  Just specify USE="-snmp" - unless you desperately need snmp, that is.

----------

## NeddySeagoon

miket,

Without avahi you don't get auto printer discovery but who cares?

A printer is like a server, it should have a static IP.

Once that's set up it just works.

----------

## miket

 *NeddySeagoon wrote:*   

> Without avahi you don't get auto printer discovery but who cares?
> 
> A printer is like a server, it should have a static IP.
> 
> Once that's set up it just works.

 

I know that quite well.  Tell me then about snmp.  I was under the impression that I need that to do network printing at all.  If I don't, then I'll surely disable the snmp flag and keep using hplip as I always have.

----------

## Goverp

 *miket wrote:*   

> ... Tell me then about snmp.  I was under the impression that I need that to do network printing at all.  If I don't, then I'll surely disable the snmp flag and keep using hplip as I always have.

 

snmp is network management device monitoring - sort of the network version of what SMART is to disks.  IMHO you don't need it unless you're running a site network with loads of printers and PCs and the like.

----------

## miket

So then I'll give it a go with USE=-snmp and see if I can still print  :Smile: 

----------

## figueroa

Excellent.  I set the following in /etc/portage/package.use:

```
media-gfx/sane-backends threads -zeroconf -sane_backends_escl

net-print/hplip  fax hpijs libusb0 scanner -snmp
```

adding  -zeroconf -sane_backends_escl to sane-backends and -snmp to hplip. Then rebuilt those two packages with emerge -uDU @world -a after which

```

# emerge -ca

 * Always study the list of packages to be cleaned for any obvious

 * mistakes. Packages that are part of the world set will always

 * be kept.  They can be manually added to this set with

 * `emerge --noreplace <atom>`.  Packages that are listed in

 * package.provided (see portage(5)) will be removed by

 * depclean, even if they are part of the world set.

 * 

 * As a safety measure, depclean will not remove any packages

 * unless *all* required dependencies have been resolved.  As a

 * consequence of this, it often becomes necessary to run 

 * `emerge --update --newuse --deep @world` prior to depclean.

Calculating dependencies... done!

>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 media-video/ffmpeg-chromium

    selected: 100 

   protected: none 

     omitted: 102 

 net-dns/avahi

    selected: 0.8-r5 

   protected: none 

     omitted: none 

 dev-qt/qttest

    selected: 5.15.3 

   protected: none 

     omitted: none 

 app-doc/xmltoman

    selected: 0.4-r1 

   protected: none 

     omitted: none 

 dev-libs/libdaemon

    selected: 0.14-r3 

   protected: none 

     omitted: none 

 acct-user/avahi

    selected: 0-r1 

   protected: none 

     omitted: none 

 acct-group/netdev

    selected: 0-r1 

   protected: none 

     omitted: none 

 acct-group/avahi

    selected: 0-r1 

   protected: none 

     omitted: none 

All selected packages: =acct-group/netdev-0-r1 =app-doc/xmltoman-0.4-r1 =acct-user/avahi-0-r1 =media-video/ffmpeg-chromium-100 =acct-group/avahi-0-r1 =net-dns/avahi-0.8-r5 =dev-libs/libdaemon-0.14-r3 =dev-qt/qttest-5.15.3

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No]
```

so I let it rip.

Restarted saned (avahi servicees were not running), and scanners still found and hplip printing still works. Made me happy.

----------

## miket

 *miket wrote:*   

> So then I'll give it a go with USE=-snmp and see if I can still print

 

Ah, no.  When I emerged the new hplip with USE=-snmp, nothing printed and hplip was unhappy.  The printer showed up in the CUPS printer-management pages, in the KDE printer settings, and in hplip, but the printer would not stay un-paused.  Print jobs would show up in the queue, but nothing went to the printer.

This is a problem since I always use networked printers.  The printer's web server was consistently available.

One indication of hplip's unhappiness:  if I clicked on View Printer and Device Information link under the Actions tab in the GUI, I got an error message about how it was unable to open the device:

```
Unable to open device hp:/net/OfficeJet_Pro_7740_series?hostname=[redacted]
```

Another indication, with USE=-snmp, hplip's Device Discovery page had the network-selecting radio buttons are disabled.  I think that they could play nicely without snmp if they wanted, but they choose not to.

When I reverted to hplip 3.20.6 (hooray for binary-build hosts!), printing was happy again.  Those queued print jobs now printed.

So now I'm back open to suggestions on how to get recent versions of hplip to work over a network without having to merge avahi.  Sigh--for now I'll have to put automake 1.13 into my overlay (hplip 3.20.6 is already there).

----------

## figueroa

Here is the meat of my "eix hplip" output:

```
Installed versions:  3.22.2(11:52:04 PM 06/13/2022)(X fax hpcups hpijs libnotify libusb0 policykit qt5 scanner -doc -kde -minimal -parport -snmp -static-ppds PYTHON_SINGLE_TARGET="python3_9 -python3_8 -python3_10")
```

I don't rely on hplip to find my printer. My usual network printer setup uses LPD with a static IP address, i.e.

```
 lpd://192.168.0.204/lp
```

My one HP printer is an HP LaserJet 3055.

----------

## dr_wulsen

IPP(S) should work even better. Since IPP(S) goes both ways, you can see the status of your jobs and more status info than with LPD, so the internet says.

I do have a printer on my network, my CUPS url to it is simply 

```
ipps://hl-2350.lan:443
```

but ipps needs setup on the printer side. For starters, just try 

```
ipp://printer.localdomain:631
```

 or whatever your printers DNS name or IP address is.

You can query your printers IPP capabilities via ipptool:

```
#sudo ipptool -tv ipp://hl-2350.lan:631/ipp get-printer-attributes.test
```

and it does the same on port 443 with IPPS.

The reply will give you the correct (as in "HP wants it that way" correct) URL for use with CUPS.

For example, my Brother printer replies with a load of info, relevant part is:

```
printer-uri (uri) = ipps://hl-2350.lan:443/ipp
```

----------

## charles17

 *miket wrote:*   

> So now I'm back open to suggestions on how to get recent versions of hplip to work over a network without having to merge avahi.  Sigh--for now I'll have to put automake 1.13 into my overlay (hplip 3.20.6 is already there).

 Maybe the Driverless printing wiki article could be of help for you?

----------

## Goverp

FWIW I print to an hplip printer over the network - my printer is attached to a Raspberry Pi (running Arch).  It runs hplip.  I have a printer on my desktop machine called RawRemote, configured in CUPS as 

ipp://foo:631/printers/RAW_PRINTER

using the hpcups 3.22.2 driver for a hp cp1700 colour ink jet.

----------

## miket

Ahh, bigger sigh.

The really nice thing about hplip is that it gives a quick way to see detailed status of my HP printer, especially to see ink levels and detailed status settings.  It's never been terribly important to me for installing printers, especially since I always set up the printer's address in my DNS.  It's a real bother that it insists on going through snmp to talk to an existing printer.  I call that a huge design flaw.  As I've noted, CUPS has no problems in reaching the printer.  I may just have to get rid of hplip.

 *charles17 wrote:*   

> Maybe the Driverless printing wiki article could be of help for you?

 I had that in mind.  I gave it a try before; I'll have to give it another go.

----------

## Goverp

 *miket wrote:*   

> ... It's a real bother that it insists on going through snmp to talk to an existing printer.  I call that a huge design flaw.  As I've noted, CUPS has no problems in reaching the printer.  I may just have to get rid of hplip...

 

It's probable that hplip uses SNMP to ask the printer about ink levels; as mentioned before, SNMP is a network management protocol, and this is managing a device over the network.  It's not a design flaw, it's a feature.  CUPS has no problem as it only sends stuff to a printer (OK, there's a handshake too, but no questions about How Much Ink Do You Have?)

----------

## miket

 *Goverp wrote:*   

> It's probable that hplip uses SNMP to ask the printer about ink levels; as mentioned before, SNMP is a network management protocol, and this is managing a device over the network.  It's not a design flaw, it's a feature.  CUPS has no problem as it only sends stuff to a printer (OK, there's a handshake too, but no questions about How Much Ink Do You Have?)

 

Ah, no.  They already expose a web server.  They ought to be doing that kind of query over HTTP like everyone else does.

----------

