Elaborate to the monitors (Healthchecks and Uptime Kuma) when IP detection fails

[favonia]

@JvdMaat Hi, let's start a new issue to fix the bug. As mentioned earlier, I am curious about whether Uptime Kuma will retain "OK" after pining a push monitor with the following sequence:

1. https://uptimekuma.mydomain.com:3002/api/push/abcdefg?status=up&msg=OK&ping=
2. https://uptimekuma.mydomain.com:3002/api/push/abcdefg?status=down&msg=&ping=

I forgot to say thank you for your reporting. 😁

[JvdMaat]

Line 1 brings the monitor up the second I click on it.
Line 2 brings it down the second I click on it.
But the Message in UptimeKuma is "OK" in both instances.
I then tried this: (To get ahead of where I think you're going)
https://uptimekuma.mydomain.com:3002/api/push/abcdefg?status=down&msg=IPv6Failed&ping=
Which brought the monitor down, and the Message was IPv6Failed.
I then did: https://uptimekuma.mydomain.com:3002/api/push/abcdefg?status=up&msg=IPv6Failed&ping=
Which brought it back up, but with the IPv6Failed message.

TL;DR. The status =up/down sets it up or down in UK. The msg will be shown as the Message in the logs (but only on status change from up/down)

[JvdMaat]

And regarding your IPv6 comment. I officially have IPv6 on my router. I had it on my main network as well, but I think I ended up turning it off as it was causing issues. Due to a router limitation I could only DHCP my IPv6 range to my main subnet, and I couldn't get it on the IoT network, or the tenant's network. (And my docker host is on the IoT network).
So personally I just ignored the IPv6 error that way if I ever get IPv6 working internally, it'll work automagically.
But I see where you're coming from that it is an error (though not fatal, as IPv4 DDNS does get updated).
So maybe have the msg be something like:
https://uptimekuma.mydomain.com:3002/api/push/abcdefg?status=up&msg=IPv6 configured but not detected&ping=
or
https://uptimekuma.mydomain.com:3002/api/push/abcdefg?status=down&msg=IPv6 failed. Update DOMAINS environment variable to IP4_DOMAINS&ping=

(To be honest, I just did a thorough search of your README, and I couldn't find a way to disable IPv6 except to update DOMAINS environment variable to IP4_DOMAINS. And it doesn't say anywhere it should be disabled if not available. So you'll find that 95% of your userbase likely has IPv6 enabled in CFDDNS, but not actually available on their network (or not configured to work with CFDDNS correctly)).

Also, I just tested those two lines, and they work with spaces and all.
And I also found out that if the status is down, and you send a new status=down push with a different message, that will show up in the logs. (I am assuming the same holds true for an up state with a new msg, but did not test)

[JvdMaat]

And last comment (for now). I did just update my docker compose to IP4_DOMAINS, and lo and behold, Uptime Kuma now says CFDDNS is up.
(So to your credit, CFDDNS is working with UK as long as there's no errors ;) )

[favonia]

@JvdMaat Thank you! I will think about how to improve README, but FYI, you can add IP6_PROVIDER=none to disable IPv6. (I thought you would see the hint If your network does not support IPv6, you can disable it with IP6_PROVIDER=none when it first fails. Could you confirm that it's missing? If it's missing there's a bug I want to fix.)

[favonia]

Line 1 brings the monitor up the second I click on it.
Line 2 brings it down the second I click on it.
But the Message in UptimeKuma is "OK" in both instances.

So the difference between Healthchecks and Uptime Kuma is that Uptime Kuma by default will "keep" the previous message that was for successful pings. I found this very confusing, but can certainly add some hacks work around it.

@JvdMaat believe the main solution here is to say what has failed and I have updated the issue accordingly. Thank you again for your report.

[JvdMaat]

I do not have the IP6_PROVIDER set.. Logs show:

Changed IP4_DOMAINS back to DOMAINS and added the IP6_PROVIDER, and now it's:

[favonia]

@JvdMaat The hint means that you can add IP6_PROVIDER=none. The updater will check all the settings and try to come up with a coherent global plan. So, if you only specify domains for IPv4, it will disable IPv6 for you, because there are no domains waiting for an IPv6 address. If you have DOMAINS=... and IP6_PROVIDER=none, the updater will also know that you don't want IPv6. I tried to make sure the updater will always come up with the most reasonable plan, so there are multiple ways to achieve the same result. You can either do IP4_DOMANS=... as you did now, or add IP6_PROVIDER=none.

What I am wondering is why the updater did not seem to give you a hint that you can add IP6_PROVIDER=none in your original setup. If you have time doing more experiments, I would like to see whether you can see that if we revert it back to DOMAINS=... without IP6_PROVIDE=none. I consider the absence of that useful hint a serious UI bug.

[JvdMaat]

So the difference between Healthchecks and Uptime Kuma is that Uptime Kuma by default will "keep" the previous message that was for successful pings. I found this very confusing, but can certainly add some hacks work around it.

I just did a bunch of URL testing.. And I take back my earlier report that you could update the message if the monitor is already in a state. That did not work again. (Not sure why it worked that one time).
Also, if msg is empty, it assumes "OK". In all other cases, it prints the message on status change between up/down.
(I set the status to up with a different message text, and then down with no msg, and it just said OK as the message)

[favonia]

@JvdMaat Well, assuming the message is OK when the status is down is certainly confusing. 😅 Thanks for the report. I'm tracking this bug at #616.

[JvdMaat]

What I am wondering is why the updater did not seem to give you a hint that you can add IP6_PROVIDER=none in your original setup. If you have time doing more experiments, I would like to see whether you can see that if we revert it back to DOMAINS=... without IP6_PROVIDE=none. I consider the absence of that useful hint a serious UI bug.

Ok, my original setup with DOMAINS, and no IP6 variables:

The hint is there on failure:

[favonia]

@JvdMaat Thanks for the confirmation! I will still work on the README (tracked at #617).

[favonia]

Actually the fix is still not great. It should skip all the "success" messages when "error" messages are present.

[JvdMaat]

Ok. Let me know if you have a version to test, and I can fiddle with the various combinations of IP6 and how that looks in UptimeKuma.

[favonia]

@JvdMaat Thanks for the volunteering. (I don't expect that you would have time to test it again.) The edge tag (the development version) should show "Failed to detect the IPv6 address" in Uptime Kuma. However, I don't want to claim I know how Uptime Kuma really works. 😅 Maybe I have to check its source code some day...

[JvdMaat]

Some quick testing. With either IP4_DOMAINS, or IP6_PROVIDER=none (ie, IPv6 disabled), UptimeKuma shows up and OK.
With IP6 enabled, but failing it shows the appropriate message:

[favonia]

@JvdMaat Thank you, but it seems there's still a strange "OK" there?

[JvdMaat]

I manually ran the URL to set it down at 11:36:40 with no msg. (Just so Cloudflare DDNS could set it to up with the OK)

[favonia]

@JvdMaat Got it. Guess the problem is solved. I honestly think you (as an Uptime Kuma user) should/can complain about why it's still showing "OK" when status is down. 😅 (Maybe it's because the updater explicitly sent "OK" when it works? It's confusing either way.)

I will not release the new version immediately because you are not suffering from the bug after disabling IPv6, and there's no security concern, either. I hope that's okay for you. If you are fine with this, I encourage you to switch back to the lastest tag because I have been using edge for testing new features.

[JvdMaat]

Sounds good. I'll switch back to 1.11.0. And yeah, I now have IP6 disabled, and UptimeKuma working perfectly.

Thanks!

[JvdMaat]

@JvdMaat Got it. Guess the problem is solved. I honestly think you (as an Uptime Kuma user) should/can complain about why it's still showing "OK" when status is down. 😅 (Maybe it's because the updater explicitly sent "OK" when it works? It's confusing either way.)

Maybe since it does send a push notification, but with status=down?
But from some quick testing looks like if msg is omitted or blank, it just uses OK as the default message. So UK assumes the sending party will include a message, and if not, substitutes OK as the default.
I just stopped my Cloudflare DDNS container to see if that will also give a down with OK message, or if the Message will be different. Will update in 10+ minutes once the monitor times out on getting a push.

[JvdMaat]

And there it is:

So yeah.. UptimeKuma will just use OK if no msg is specified.