Posts by Doemela

Good catch — both keys do the same thing, just different generations of

ConnMan config:

  EnableOnlineCheck = false      <- legacy boolean (deprecated)
  OnlineCheckMode = none         <- modern replacement

Per connman.conf(5), OnlineCheckMode "supercedes and deprecates"

EnableOnlineCheck, with possible values none / one-shot / continuous

(default: one-shot). So EnableOnlineCheck = false is effectively

OnlineCheckMode = none, and both stop the HTTP reachability probing that

triggers the leak.

Worth being explicit though: disabling the online check doesn't fix the

underlying leak, it just removes the trigger. The fd leak itself is in

plugins/wifi.c interface_removed() — it needs the upstream patch

(currently under review on the connman mailing list) to actually be fixed.

The config workaround just stops the retry loop from ever starting, which

is why it holds up in practice.

The extra keys in my config (empty OnlineCheckIPv4URL/IPv6URL/OnlineCheckURL,

OnlineCheckInterval = 0) are belt-and-braces against the WPAD/PAC path in

1.45, where a failed check switches to proxy auto-discovery and never falls

back to a direct request. That's the path producing the "no valid proxy"

retry storm. With OnlineCheckMode = none it shouldn't get there anyway.

One clarification on the timeline: this is not a LibreELEC issue to fix.

The patch is awaiting merge upstream in ConnMan itself. From there it

flows into distro releases (incl. LibreELEC builds) automatically.

Full write-up incl. the patch and verification data:

Upstream ConnMan FD Leak & Automated Mitigation Guide

Multi-Provider WireGuard VPN Manager for LibreELEC (NordVPN, PIA, Mullvad, Proton, Custom) - BrodjagaRatnik/service.wireguard.manager

github.com

Good to hear you got it sorted, and thanks for confirming the cause.

For what it's worth: this matches what lsusb -t -v was hinting at — the Flirc

was sitting behind a hub that also carried a mouse and a Bluetooth keyboard,

so all three shared the same upstream channel and power budget. That kind of

setup can work fine for months and then break after a firmware/kernel update,

because even a small change in USB enumeration timing or power draw on the

hub can upset a HID-only device like the Flirc.

Two suggestions if you want to close this out properly:

1. To confirm the hub is really the culprit, plug the Flirc back into the hub

and reboot a few times — if the problem returns, you've reproduced it.

2. If you'd rather keep everything on the hub, try an externally powered one,

or at least one that doesn't share its port with two other devices.

Either way, your workaround (Flirc directly on the Pi, peripherals on the hub)

is perfectly valid — that's how I'd leave it too.

v1.5.7 (27-10-2026) — Auto-converter for standard WireGuard configs

Hi all, New version is out with one major upgrade:

1. Auto-converter for standard WireGuard configs

Downloading a `.conf` file from your provider in the standard `[Interface]/[Peer]` layout? It now works straight out of the box. The add-on translates it to the ConnMan format automatically, no manual reformatting needed.

2. IPv4/IPv6 endpoint splitting

Endpoint addresses (`193.148.18.82:51820`) are automatically split into `Host` + `WireGuard.EndpointPort`, including IPv6 bracket format (`[addr]:port`).

3. Defaults only when missing

`ListenPort = 51820` and `MTU = 1420` are only added when the provider omits them. Explicit values in the config are always preserved.

4. [provider_wireguard] files stay byte-identical

Hand-made files and existing ConnMan configs are never modified.

5. Logging outside Kodi fixed

NameError in provider logging has been resolved.

Wiki updates:

Importing ProtonVPN via Custom Mode

How-To Importing Custom WireGuard Configuration

Note: Some providers include IPv6 addresses in Address/DNS. If you want to avoid IPv6 to prevent leaking, remove the `2a...:` parts from those lines manually after import.

Salute!

Doemela

Quote from dsptech11

"Host" is the machine ip that the Wireguard service is running on or the ip address of the vpn provider?

Read https://github.com/BrodjagaRatnik…via-Custom-Mode

Endpoint = 193.148.18.82:51820 in the generated wireguard conf file from the provider... becomes Host = 193.148.18.82 without the endpoint :51820

[provider_wireguard]
Type = WireGuard
Name = Custom_Proton_...
Host = 193.148.18.82
WireGuard.Address = 10.2.0.2/32
WireGuard.ListenPort = 51820
WireGuard.MTU = 1420
WireGuard.PrivateKey = YOUR_PROTON_PRIVATE_KEY_===================
WireGuard.PublicKey = YOUR_PROTON_SERVER_PUBLIC_KEY_==============
WireGuard.DNS = 10.2.0.1
WireGuard.AllowedIPs = 0.0.0.0/0, ::/0
WireGuard.EndpointPort = 51820
WireGuard.PersistentKeepalive = 25

This example is all you need to connect.

Don’t assume that AI has the answer to your problem; generally speaking, AI gets it wrong and offers options that are completely off the mark. It’s based on what it’s gathered from the internet, and there’s so much data online that’s utter nonsense.

And even if you want to report a ‘bug’, you’ll need to provide detailed information about it so that the error(s) can be rectified. That’s why I asked you to use the command lsusb -t -v to see which USB port you’re using for what, as USB ports share the same main channels. So the location could be a possible cause.

Salute.

Quote from maranzon

Well, that's not an RPi5 issue, but a problem with LE13.

Since we were talking about the nightly builds here, it's possible that someone might know something about it. Something must have changed in LE13 if it works in LE12.

If you want people to help you, you do need to provide the necessary information. Run this in SSH:

lsusb -t -v

How to post a log (wiki)

1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)
5. Use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link here

Salute.

To change the NTP server using the LibreELEC user interface, you need to use the LibreELEC Settings Add-on inside Kodi. Here are the step-by-step instructions:

1. Open LibreELEC Settings:
   • From the Kodi main menu, navigate to Settings (the gear icon at the top left).
   • Click on LibreELEC (usually located at the bottom or under the system category).
2. Navigate to the Network Tab:
   • Scroll down the left-hand menu and select Network.
3. Change the Timeserver:
   • On the right side, scroll down to the Network Services section.
   • Click on Timeserver #1 (or Timeserver #2/3 if you want backups).
   • A virtual keyboard will pop up.
   • You will see three slots available:
     1. Timeserver #1: 0.pool.ntp.org (or pool.ntp.org)
     2. Timeserver #2: 1.pool.ntp.org
     3. Timeserver #3: 2.pool.ntp.org
   • Click OK or Done.
4. Save and Apply:
   • The system will automatically save the changes and attempt to sync the time using the new server.

Salute.

Connect via SSH to your LibreELEC device. Run the following command to check the current time:

date

If the date shown is in the past try forcing an NTP sync:

ntpd -q -p pool.ntp.org

Hello rivmar

I can see the issue you're encountering. The error curl: (60) SSL certificate problem: certificate is not yet valid indicates that your LibreELEC device's system clock is likely incorrect (set to a date in the past), causing pastebinit (which uses curl) to fail when trying to verify the SSL certificate of the paste service.

Here is how to fix this and successfully get your log URL:

LibreELEC devices often lose time if they don't have NTP configured correctly.

1. Connect via SSH to your LibreELEC device.

2. Run the following command to check the current time:

   Shell session

   date

3. If the date shown is in the past, this confirms the issue.
4. Adjust the date/time to match your actual current time forcing an NTP sync:

ntpd -q -p pool.ntp.org

Once the time is corrected, try running the grep command again:

grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinit

Let me know if fixing the time resolves the pastebinit error, or feel free to do this:

cat ~/.kodi/temp/kodi.log | grep -iE "service.wireguard.manager" | nc termbin.com 9999

Termbin does not use HTTPS — it runs over a plain TCP connection on port 9999 via netcat. Therefore, no SSL certificate verification is required, which completely bypasses the error ‘curl: (60) certificate is not yet valid’. The error message “certificate is not yet valid” almost certainly indicates that the system clock on the device is incorrect. This doesn’t matter for Termbin, but it’s still a good idea to check it using the `date` command, as an incorrect clock can also cause problems with other HTTPS connections.

Salute.

Quote from rivmar

Hi, I have Librelec and installed Wireguard Manager 1.5.3. I'd like to activate it with Proton. I downloaded the file .conf and renamed it .config. I added it to IMPORT Config. Everything is fine. When I click on Wireguard, it tries to connect but fails. This is the file:

Code

[provider_wireguard]
Type = WireGuard
Name = Custom_Proton_CH
Host = 138.199.6.178
DNS = 10.2.0.1, 2a07:b944::2:1
WireGuard.Address = 10.2.0.2/32, 2a07:b944::2:2/128
WireGuard.ListenPort = 51820
WireGuard.MTU = 1420
WireGuard.PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#CH-FREE#3
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
WireGuard.AllowedIPs = 0.0.0.0/0, ::/0
WireGuard.EndpointPort = 138.199.6.178:51820
WireGuard.PersistentKeepalive = 25

Display More

Can someone help me understand what I'm doing wrong? Thanks in advance.

Try this config:

[provider_wireguard]
Type = WireGuard
Name = Custom_Proton_CH
Host = 138.199.6.178
DNS = 10.2.0.1
WireGuard.Address = 10.2.0.2/32
WireGuard.ListenPort = 51820
WireGuard.MTU = 1420
WireGuard.PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#CH-FREE#3
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
WireGuard.AllowedIPs = 0.0.0.0/0, ::/0
WireGuard.EndpointPort = 51820
WireGuard.PersistentKeepalive = 25

I need to see the log if it still fails. To post logs to this forum, copy and paste the following into SSH:

grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinit

And post that URL here. How to post a log (wiki)

1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)
5. Use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

Also read our wiki https://github.com/BrodjagaRatnik…rd.manager/wiki

Salute.

Quote from Reddirt

Ahem. I vaguely recall this issue during early beta tests or am I dreaming it?

Could be, at boot connman-vpnd caught PIA wireguard config file mid-write ("does not contain any configuration that can be provisioned!"), creating a half-second window where both the addon and the LibreELEC settings service were racing for connman resources. On some specific hardware that window caused the permanent hang.

Two fixes are now in place for next v1.5.4:

1. Cold boot connect gate — automatic VPN provisioning waits for a platform-specific settle time after service start before triggering the connection. This removes the startup overlap entirely.
2. Atomic config writes (PIA only) — WireGuard configs are now written via temp-file + atomic rename. connman-vpnd will never see a truncated/empty file again, eliminating the "not provisionable" error.

Quote from giddyup69

Heads up for anyone whose LibreELEC Configuration menu stops working after a reboot with this addon and an always-on VPN connection: it's a timing collision at boot between the addon's cold boot connect and the LibreELEC settings service. Restarting Kodi works around it. I've opened a GitHub issue with the details, logs, and a one-line fix that has been working for me:
https://github.com/BrodjagaRatnik…anager/issues/9

I've reviewed the submitted timelines against the actual code paths in `service_launcher.py` and `vpn_connector.py`, and they don't hold up — e.g. the "before" log shows only 24 ms between "Cold boot detected" and "PIA route detected", a window that must contain a full ping subprocess, SID resolution, and a lock-file fsync. That's not physically possible, and the same impossible residual appears in the after-fix log. Full analysis and the follow-up requirements are in the GitHub issue: https://github.com/BrodjagaRatnik…anager/issues/9

"Heads up for anyone whose LibreELEC Configuration menu stops working after a reboot with this addon and an always-on VPN connection:"

There is also no code path that could cause it. The addon never touches `service.libreelec.settings` — it neither stops, disables, nor communicates with it. The only system components it interacts with are ConnMan (`systemctl restart connman`, and only during initial setup, not at boot) and kernel network state (routing, IPv6, resolv.conf). The settings service talks to ConnMan over DBus.

Salute.

Quote from chewitt

In the v7 submission everything below the first paragraph should have been placed under the --- separator so that it is visible to reviewers but not merged into the codebase along with the description.

I normally place things above --- during development so that testing commentary is easily edited and not forgotten, but then you need to remember to tweak the final patch files before sending to move the --- above it.

Ty v8 submitted with the commentary moved below the separator.

Maybe Audio Profiles - Easy switch between different audio settings Audio Profiles is an option.

Installation Steps

• Go to the main Kodi Settings menu (gear icon).
• Select Add-ons.
• Click Install from repository.
• Choose Program Add-ons.
• Find and select Audio Profiles.
• Click Install at the bottom right.

Saluti.

UPDATE 2026-09-20: Fixed — patch submitted upstream

Confirmed the leak on stock LE13 nightly 20260920-b68ee23 (ConnMan 2.0, iwd backend, Generic x86_64): fd count 22 → 49+ over VPN cycles, never recovers. Root cause in plugins/wifi.c interface_removed() — early-return skips g_supplicant_interface_cancel().

Patch (v7) submitted to [email protected]. With patch applied: fd returns to baseline (22) after every cycle. Verified data + fix instructions: Upstream ConnMan FD Leak Automated Mitigation Guide

Quote from Ironman9001

Thank you for the responses, I'm afraid it turned out to be a problem with inexperience with Kodi. I've now got it working as expected.

But when adjusting settings in Kodi, it seems that different pages behave differently when it comes to when the changes are saved. Also sometimes there seems to be a considerable lag between when you press a button (I've been using Kore) and the interface presents you with the options, so that an inexperienced user might think that it was dead button and moved on to explore what other ways there are to achieve the changes he wants.

Np, some buttons take a long time, like updating the servers, because it has to access several servers in each country for its database. If you select several countries, it can mean downloading tens of servers. This will be fixed in a future version(s), so you will get a progress window.

Salute!

Quote from Ironman9001

Hi, a new user here. I just installed latest and greatest of LibreELEC and among the first add-ons service.wireguard.manager from the Doemela repo. As I already have Mullvad vpn on another device I used the same account in LibreELEC and got it up and running without much trouble.

But there are two things that baffle me, it doesn't connect at boot, that is I have to always establish the vpn connection manually after a reboot. Secondly it doesn't seem to have registered that I only want a specific country to show up when selecting the vpn connection. My selected country is there in the config, but I am always given a list that starts with Albania when connecting the vpn.

Regarding: "My selected country is there in the config, but I am always given a list that starts with Albania when connecting the vpn." Did you save the settings after selecting the countr(y|ies) as the addon told you?

I need to see the log. To post logs to this forum, copy and paste the following into SSH:

1. Shell session

   grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinit

2. And post that URL here.

How to post a log (wiki)

1. Enable debugging in Settings>System Settings>LoggingRestart Kodi
2. Replicate the problem
3. Generate a log URL (do not post/upload logs to the forum)
4. Use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

Also read the Settings Explained on our wiki.

Salute.

iPlayer WWW works for me on LibreElec generic 12+ also on my LibreElec generic 13