SSL error on siteMonitor service (with self-signed certificate)

[Kimbaras]

Description

Hi all,

I was trying to setup a monitor of the wireless access points around the house.
At first I've tried with a "ping" which would be sufficient (if the AP is responding then it's up) but ping is always returning a down results (not sure why, the AP is responding to the ping both from the host as well as from the container with docker exec homepage ping <ip>)
This will be a different discussion tho...

I've tried changing it to siteMonitor as it's working better with other services but I'm getting an SSL error in the log (see attached).

For what it matters, the access point in question is an Aruba AP, which redirects automatically all requests (either HTTP or HTTPS) so the https://ip:4343 port which provides a self-signed certificate.

I've read in a different discussion / bug that the self-signed cert should not be an issue, but seems not in this case.
It could be related to the protocol of the reply from the AP (at least by the error reported) but I can't be sure about that.

Thanks!

homepage version

v0.10.9 (b5f4daa, Jan 6, 2025)

Installation method

Docker

Configuration

- Access Point X:
            icon: /icons/aruba.png
            href: https://<AP IP address>:4343/
            description: Access Point X
            siteMonitor: https://<AP IP address>:4343/

Container Logs

[2025-02-21T15:49:38.463Z] error: Error calling https://:4343/...
[2025-02-21T15:49:38.482Z] error: [
500,
Error: write EPROTO A04C5A9D7F000000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:921:

  at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) {
errno: -71,
code: 'EPROTO',
syscall: 'write'

}
]

Browser Logs

No response

Troubleshooting

docker exec homepage ping : the AP respond correctly to the ping

/app # curl -L -k https://AP-IP:4343/
curl: (35) TLS connect error: error:0A000152:SSL routines::unsafe legacy renegotiation disabled

[shamoon]

If you google this you will see it’s not about self-signed certs it’s about legacy TLS negotiation, which is not something we’re going to change. I would look back at ping since that’s actually what you want. What’s the problem there?

[Kimbaras]

Thanks for the feedback.

Regarding ping, well the problem is there is no problem yet the host / service is reported as down in homepage...
Let me explain.

I've updated the config for the host I'm trying to monitor as follow

- Access Point X:
            icon: /icons/aruba.png
            href: https://<AP IP address>:4343/
            description: Access Point X
            ping: 192.168.1.250

Which if I understood correctly the docs should be the correct config.
I've checked if the host and the container are able to ping the endpoint, and they are

From host machine

From the docker

Yet in homepage I get the service as "Down", which clearly is not.

I was listening on the logs while restarting the container and there is no error pointing to that IP.

Thanks!

[shamoon]

Well certainly that suggests a permissions issue, as ping is being run on the host machine, so you can investigate that. Im not sure why its not outputting an error for that in the logs, you haven't provided much info about the response but the code tries to catch any error with the ping call and log it, very simply:

homepage/src/pages/api/ping.js

Lines 35 to 43 in 666d075

	try {
	const response = await ping.probe(hostname);
	return res.status(200).json(response);
	} catch (e) {
	logger.debug("Error attempting ping: %s", e);
	return res.status(400).send({
	error: "Error attempting ping, see logs.",
	});
	}

My guess is what you're seeing above doesn't actually throw an error which sounds like at most an issue with https://www.npmjs.com/package/ping

[Kimbaras]

I'm sorry but these tests

From host machine

From the docker

do not rule out an issue with the ping from either the host machine as well as the docker container?
It's a genuine question I don't want to seems rude or anything.

I've also tried to connect directly to the container and tried a "manual" ping from there, which should be the same as the docker exec test, and seems to be working

Regarding providing info about the response, here additional info:

The request as seen from the browser console

This is the header response of such request

And this is the results from the browser console (Preview and Response tabs shows basically the same)

I've also checked again the logs starting from the container stopped and listening on them and I confirm that no error about the ping or such host (192.168.1.250) are present.

Let me know if I can provide any additional info in order to further troubleshooting this.

Thanks!

[shamoon]

As I guessed above, the issue with ping seems to be in the wrapper package we use: danielzzz/node-ping#158

[Kimbaras]

That translate as "we'll need to wait for that fix in order for this to work" right?

Thanks!

[shamoon]

Yea, it doesn't seem like something we can fix on our end. Im not clear how active that is though, its a pretty old thread