Unable to download plugin

[mr2c12]

I'm running the container via docker, to be able to configure my HP LaserJet P1005.

If I bind the entire /dev (BONUS QUESTION: is this approach the correct one?) I am able to add the printer - which is found.
This printer requires a proprietary plugin, which I am not able to download.

On the logs I can see some generic entries:

E [2026-01-06T08:16:47.338Z] Unable to open HPLIP plugin status file /var/lib/hp/hplip.state
E [2026-01-06T08:16:48.421Z] Unable to download file http://hplip.sf.net/plugin.conf
E [2026-01-06T08:16:48.421Z] Unable to download plugin index
E [2026-01-06T08:16:48.421Z] Unable to download plugin ...

Trying to replicate the download via shell:

% docker exec -it hplip-printer-app /bin/bash
root@mikfourteen:/# wget http://hplip.sf.net/plugin.conf
--2026-01-06 10:28:39-- http://hplip.sf.net/plugin.conf
Resolving hplip.sf.net (hplip.sf.net)... 104.18.21.237, 104.18.20.237
Connecting to hplip.sf.net (hplip.sf.net)|104.18.21.237|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://hplip.sf.net/plugin.conf [following]
--2026-01-06 10:28:39-- https://hplip.sf.net/plugin.conf
Connecting to hplip.sf.net (hplip.sf.net)|104.18.21.237|:443... connected.
ERROR: cannot verify hplip.sf.net's certificate, issued by 'CN=E8,O=Let's Encrypt,C=US':
Unable to locally verify the issuer's authority.
To connect to hplip.sf.net insecurely, use `--no-check-certificate'.

I don't know if it's related to the error in the printer app.
(Id "--no-check-certificate" is included, then wget completes the download just fine).

Should you need further details, please just let me know.

[rudra-iitm]

Hi @mr2c12,
Could you please share the entire log? I need to check whether there are any permission issues causing this.

[mr2c12]

The log reported is pretty much it all. That's what is reported on the web interface.

Any way for me to get to a more complete log?

[tillkamppeter]

You need to switch the logging into debug mode. To do so, go to the logging part in the web interface and switch he log level there. Then go to the plugin part of the web interface to trigger another attempt of loading the plugin. After that, provide us with the log which you have then.

[mr2c12]

Here it is:

I [2026-01-10T13:00:06.159Z] [Client 39] Accepted connection from 'localhost'.
I [2026-01-10T13:00:06.160Z] [Client 39] HTTP_STATE_GET http://localhost:6031/plugin HTTP/1.1 (en-US,en;q=0.5)
E [2026-01-10T13:00:06.160Z] Unable to open HPLIP plugin status file /var/lib/hp/hplip.state
I [2026-01-10T13:00:06.160Z] [Client 39] OK text/html 0
D [2026-01-10T13:00:06.160Z] [Client 39] Using HTTP Accept-Language value 'en-US,en;q=0.5' for localization.
D [2026-01-10T13:00:06.160Z] [Client 39] Using language 'en'.
I [2026-01-10T13:00:06.160Z] [Client 39] Closing connection from 'localhost'.
I [2026-01-10T13:00:07.614Z] [Client 40] Accepted connection from 'localhost'.
I [2026-01-10T13:00:07.614Z] [Client 40] HTTP_STATE_POST http://localhost:6031/plugin HTTP/1.1 (en-US,en;q=0.5)
E [2026-01-10T13:00:07.614Z] Unable to open HPLIP plugin status file /var/lib/hp/hplip.state
D [2026-01-10T13:00:07.614Z] [Client 40] Read 94 bytes of form data (application/x-www-form-urlencoded).
D [2026-01-10T13:00:07.614Z] Downloading the proprietary plugin ...
D [2026-01-10T13:00:07.614Z] Getting plugin index from HP ...
D [2026-01-10T13:00:07.614Z] Downloading http://hplip.sf.net/plugin.conf
D [2026-01-10T13:00:07.968Z] Download status: 60
E [2026-01-10T13:00:07.968Z] Unable to download file http://hplip.sf.net/plugin.conf
E [2026-01-10T13:00:07.968Z] Unable to download plugin index
E [2026-01-10T13:00:07.968Z] Unable to download plugin ...
I [2026-01-10T13:00:07.968Z] [Client 40] OK text/html 0
D [2026-01-10T13:00:07.968Z] [Client 40] Using HTTP Accept-Language value 'en-US,en;q=0.5' for localization.
D [2026-01-10T13:00:07.968Z] [Client 40] Using language 'en'.
I [2026-01-10T13:00:07.969Z] [Client 40] Closing connection from 'localhost'.
I [2026-01-10T13:00:09.200Z] [Client 41] Accepted connection from 'localhost'.
I [2026-01-10T13:00:09.200Z] [Client 41] HTTP_STATE_GET http://localhost:6031/logfile.txt HTTP/1.1 (en-US,en;q=0.5)
I [2026-01-10T13:00:09.200Z] [Client 41] Partial Content text/plain 2085
I [2026-01-10T13:00:09.200Z] [Client 41] Closing connection from 'localhost'.

I'm using the latest container available today (the one with persistent settings).

[tillkamppeter]

I have checked now doing just

wget http://hplip.sf.net/plugin.conf

and the file gets downloaded smoothly and it has the expected content. The downloads of the actual plugins, following the links in that file also works (but is not that relevant here).

This means that there is some problem with the access to the external server from withing the OCI container. @rudra-iitm could you have a look at that.

[mr2c12]

This is what you get running the command inside the container:

root@mikfourteen:/# wget http://hplip.sf.net/plugin.conf
--2026-01-10 14:44:29-- http://hplip.sf.net/plugin.conf
Resolving hplip.sf.net (hplip.sf.net)... 104.18.21.237, 104.18.20.237
Connecting to hplip.sf.net (hplip.sf.net)|104.18.21.237|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://hplip.sf.net/plugin.conf [following]
--2026-01-10 14:44:29-- https://hplip.sf.net/plugin.conf
Connecting to hplip.sf.net (hplip.sf.net)|104.18.21.237|:443... connected.
ERROR: cannot verify hplip.sf.net's certificate, issued by 'CN=E8,O=Let's Encrypt,C=US':
Unable to locally verify the issuer's authority.
To connect to hplip.sf.net insecurely, use `--no-check-certificate'.

[tillkamppeter]

The Printer Application downloads the files via the function hplip_download_file() in hplip-printer-app.c. The function uses libcurl to do the actual download. As curl has an equivalent to the --no-check-certificate of wget, it is --insecure, libcurl should also have such an option and options seem to be set by the curl_easy_setopt() in hplip_download_file(). Perhaps just adding a line

curl_easy_setopt(curl, CURLOPT_INSECURE, 1L);

could do the trick. Please check the documentation of libcurl, the line here is a wild guess by me.

Better would be naturally to make the certificate be actually handled correctly when downloading out of the container.

@rudra-iitm ?

[mr2c12]

Not really liking the idea of ignoring an invalid certificate.
My 2 cent.

[tillkamppeter]

Not really liking the idea of ignoring an invalid certificate. My 2 cent.

No problem, I also prefer if we could handle the certificate from within the container.

The last comment was only my attempt to follow wget's suggestion, and for quick experiments, not as a final fix for this issue.