Posts by Doemela

  • [RPi4] Timeout and digest mismatch when accessing official add-on repository

    You can take a few steps yourself to check if the blockade is being imposed by the Russian government:

    1. Use official Russian verification tools: The Russian telecom watchdog Roskomnadzor has a public database. You can enter a URL or IP address on their official website (blocklist.gov.ru https://blocklist.rkn.gov.ru https://eais.rkn.gov.ru/en/ https://help.orionnet.ru/page28734115.html https://2ip.io/rkn-blacklist/ https://www.experte.com/internet-censorship/russia) to see if it is officially on the blacklist.
    2. Use OONI Probe: This is a free, global network that measures internet censorship. You can use their app or website to check if specific websites or apps are currently being blocked in Russia via DPI techniques. https://ooni.org/
    3. Test with a VPN (outside Russia): If you are in Russia and a website does not load, turn on a good VPN that connects to a server in the Netherlands, Germany, ... . Does the website load now? Then the Russian firewall is blocking it.

    View the error code:

    • Are you getting a Connection Timed Out? This often indicates a firewall that is silently dropping the traffic.
    • Are you getting a specific HTTP 451 error code? This literally means: "Unavailable for legal reasons".

    The problems with the LibreELEC repository at the Russian provider Greenwave are almost certainly caused by government DPI (Deep Packet Inspection), which acts as a 'firewall' that slows down or blocks traffic to the LibreELEC server. Since the outage disappears when using a VPN, such as Cloudflare WARP, the connection to the German hosting provider Hetzner is likely being cut off by automatic filters. A structural solution is to permanently enable a VPN or anti-censorship tool to bypass the firewall.

    I checkt it. The IP address in question is 116.203.139.247. This is the server for addons.libreelec.tv. The server is located at Hetzner (Germany).

    The "Silent" Blockade via the TSCP system:

    If you enter this IP address on the official site blocklist.rkn.gov.ru, chances are that no official blockade will appear. This is because Roskomnadzor (RKN) has not individually banned Hetzner servers for their content; instead, the government automatically blocks and throttles large parts of the Hetzner network via their TSCP systems (the hardware filters located at providers).

    The "Cheburnet" filters (DPI):
    In recent years, the Russian government has adjusted the filters so strictly that foreign cloud and hosting providers are distrusted by default. The DPI system recognizes the downloading of .xml.gz files from a German IP address and intentionally throttles the speed to ~1.6 KB/s until the connection times out.

  • WireGuard VPN Manager

    🚀 New Release: Version 1.4.9

    [⚡] Introduction
    We are excited to announce the release of version 1.4.9! This update introduces major stability enhancements, expanded VPN compatibility, and critical bug fixes to ensure seamless connectivity and performance.

    • 🔑 Version: 1.4.9
    • 📅 Release Date: 2026-06-30
    • 🧩 Compatibility: 100% LibreELEC 11, 12, 13 compatible (verified cross-platform support for x86, Raspberry Pi 4, Pi 5, and Generic Devices). Thanks to Reddirt and deepee.

    [⚙️] Changelog

    Core & Performance Optimizations

    • Fixed memory leaks by replacing global assignments with lazy-loaded references.
    • Converted dynamic config checks from daily intervals to precision hourly parameters.
    • Relocated state variables from /tmp/ storage to profile paths.
    • Optimized hardware timing for Raspberry Pi 4, Pi 5, and Generic Device architectures.

    VPN & Routing Enhancements

    • Added ProtonVPN via Custom Mode support.
    • Initial preparation for Mullvad VPN support (currently in development).
    • Fixed dual-default gateway collision using dual-bucket /1 split routing for PIA.
    • Added forced virtual interface data-ping to block ghost handshakes of PIA.
    • Dynamic MTU scaling maximizes packet throughput over standard links for PIA.

    Network & Security Hardening

    • Added automated tunnel integrity and routing verification checks.
    • Added network diagnostic test to verify tunnel encryption and stop IPv6 leaks.
    • Hardened ConnMan loop engine to isolate custom nameservers onto active interfaces.
    • Hardened connection teardown with route cache flushing and daemon restarts.

    Bug Fixes & Automation

    • Fixed cold boot and restart detection inside Service Launcher.
    • Fixed 55-minute handshake cache lockout bug for instant connection retries for PIA.
    • Added dynamic multi-tiered latency fallback engine for robust region updates for PIA.
    • Implemented persistent 10-min anti-abuse tracking with 15-min cooldown locks for PIA.
    • Added split-title error handling to display clear server and credential alerts.
    • Added manual trigger compatibility directly via HDMI-CEC keymaps.

    [📥] How to Update
    You can update directly via the official repository. https://github.com/BrodjagaRatnik…ository.doemela

    Quote

    Always remember to back up your current profile paths and settings before performing this update!

    [💬] Feedback & Support
    Please report any issues or share your feedback in the support section https://github.com/BrodjagaRatnik….manager/issues. Thank you for using our software!

  • VPN Add-on Questions

    Quote from wizardknight

    Are there any working OpenVPN client add ons for these nighties?

    On my Coreelec boxes I use the Zomboided OpenVPN add on.

    However after adding it's repository to the latest nightly, I get a 'could not connect to repository' error.

    When traveling I use my home VPN server to provide access to my media, so it would be nice if I could get an OpenVPN client running.

    Any tips or suggestions would be appreciated.

    It just runs on Kodi Omega 21.3 for me, and you don't need the repository at all; it's not maintained any more anyway. You can just download it here: https://github.com/Zomboided/serv…eases/tag/7.0.4

  • WireGuard VPN Manager

    📢 Important Developer Update: LibreELEC 12 vs. LibreELEC 13 (LE13)

    Hi everyone,

    The current release of the WireGuard VPN Manager Add-on is fully optimized for LibreELEC 12 and is working perfectly.

    Behind the scenes, I am already preparing the backend code for LibreELEC 13. LE13 brings a massive system change: LibreELEC is permanently replacing the old network engine (ConnMan) with the industry-standard NetworkManager.

    This change has a direct impact on our add-on. Here is a quick overview of what this means for us:

    🟢 The Advantages (Why LE13 is great news)

    • Rock-Solid Routing: No more random VPN disconnects when your router refreshes its DHCP lease. NetworkManager handles traffic routing intelligently in the background.
    • Stable Handshakes: The add-on will no longer crash due to system-level proxy or WPA Wi-Fi re-keying bugs.
    • Cleaner Backend Code: NetworkManager natively understands WireGuard. This allows me to remove messy "ip route" and terminal hacks from the Python code, making the add-on much faster and lighter.

    🔴 The Disadvantages & Impact

    • Potential Breaking Change: As LibreELEC shifts its network architecture toward NetworkManager in LE13, the current ConnMan-based routing functions of the add-on may break or become unstable on newer test builds until updated.
    • Backend Transition: I am proactively preparing a code migration to ensure the core functions can seamlessly talk to NetworkManager (nmcli) alongside the existing ConnMan (connmanctl) implementation.

    📅 What is the plan?
    Enjoy the current release on LE12 for now—it works great. I will take care of the heavy lifting for LE13 in the coming period so we can transition smoothly without losing any of our advanced features.

    Stay tuned for the first LE13 test builds!

  • WireGuard VPN Manager

    Quote from Fabbz

    What you describe is not the case, I even flushed the main routing table and rebooted. Everything in the logs is fine.

    This must be something else.

    You can do:

    Shell session
    grep -Ei "error|warning" /storage/.kodi/temp/kodi.log | pastebinit
    Shell session
    journalctl -b 0 --no-pager | grep -iE "timeout|fail|network|waiting" | head -n 50 | pastebinit
    Shell session
    systemd-analyze; systemd-analyze blame | head -n 25 | pastebinit
    Shell session
    journalctl -p err..alert | pastebinit
    Shell session
    (journalctl -u vpn-watchdog.service; grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log) | pastebinit
    Shell session
    (echo "=== CONNMAN SERVICES ==="; connmanctl services; echo "=== CONNMAN STATE ==="; connmanctl state) | pastebinit
    Shell session
    journalctl -u connman | pastebinit

  • WireGuard VPN Manager

    Quote from Fabbz

    Hi,

    Thank for the update; I tried what you said but it didn't fix the route.

    Any other suggestions to check ?

    If the split routing did not override the table, ConnMan is likely aggressively caching your old network state under a temporary session. To see exactly what is going on under the hood, please run these two commands in your terminal while the VPN is active and paste the output back here:

    Shell session
    route
connmanctl services

    Without seeing your active routing table flags, it is impossible to see which interface is currently trapping your traffic. Paste those logs, and we will try to get it sorted.

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

    What happens: It pushes the filtered data straight to LibreELEC's default pastebin server and prints a clean link right inside your terminal window. Please share that link directly in this thread. Do not post full raw logs here!

  • WireGuard VPN Manager

    I looked into your routing table, and your analysis is 100% correct. The problem is a known ConnMan DNS routing conflict. Look at this specific line in your VPN routing table:

    Code
    10.2.0.1        192.168.101.254 255.255.255.255 UGH   0      0        0 wlan0

    Because you declared WireGuard.DNS = 10.2.0.1 inside your config file, ConnMan mistakenly generated a hardcoded Host route (UGH) that traps your DNS traffic. Instead of sending DNS requests inside the secure wg0 tunnel, it is forcing them out over your Wi-Fi card (wlan0) to your local router (192.168.101.254). Your local router has no idea what 10.2.0.1 is, so it drops the packets. This is why you can ping public IPs like 8.8.8.8 perfectly (via the VPN), but your DNS lookup times out, making your traceroute and reverse-DNS lookups extremely slow.

    Force the internal DNS into the tunnel you need to force the Linux kernel to override ConnMan's broken Wi-Fi route. You can do this by splitting the internet route into two smaller halves. Open your .config file and change the AllowedIPs line:

    1. Remove: WireGuard.AllowedIPs = 0.0.0.0/0
    2. Add: WireGuard.AllowedIPs = 0.0.0.0/1, 128.0.0.0/1

    Because a /1 netmask is more specific than a /0 default gateway, the kernel will ignore the Wi-Fi card and force your 10.2.0.1 DNS requests straight into the wg0 tunnel. Make sure to clean the network cache, restart ConnMan, and reconnect:

    Shell session
    rm -f /storage/.config/vpn-services/*
ip route flush cache
systemctl restart connman

  • WireGuard VPN Manager

    Quote from Fabbz

    OK, I thought something like it was missing!

    I only have routing issues with wireguard; normally no issues on other systems. Have you experienced this ?


    Thanks so far; maybe this needs to be added to your Wiki including the config template ?

    Routing issues is not wireguard if your wireguard config file has settings for a VPN provider it is OK. It is connman that handles the routing. Do this cmd in ssh before connecting to a VPN:

    Shell session
    route

    Then connect to your VPN and do that "route" command again provide that here so I can see. And provide the wireguard file note edit your WireGuard.PrivateKey = ******* we do not need that!

  • WireGuard VPN Manager

    Quote from Fabbz

    Hi,

    As my OpenVPN with Proton just stopped to work yesterday I needed to see if I could use wireguard. Can i just load an Wireguard from Proton and it should be able to connect or is it not supported yet ?

    Yes if you make/download a wireguard config name it like country.config you can import it in the add-on make sure the begin of the file is:

    [provider_wireguard]
    Type = WireGuard
    Name = Custom_Country

    Rest of Proton wireguard conf...


    Salute.

  • WireGuard VPN Manager

    Quote from Reddirt

    https://paste.libreelec.tv/nephrotoxic-derrick.log

    I tested 3 locations and only one had traffic US West optimized. Might be useful to auto update/Regenerate locations after a change.

    First do:

    Bash
    rm -f /tmp/pia_token_cache.json /tmp/pia_name_map.json

    To get rid of "2026-05-30 23:50:13.420 T:1372 error <general>: service.wireguard.manager v1.4.6~beta.4: Password decoding failed, using raw password: 'utf-8' codec can't decode byte 0xe0 in position 2: invalid continuation byte"


    On every connection, the add-on gets all data live from PIA API to request local server WireGuard configurations before handing control over to ConnMan. This auto-update/Regenerate locations on every new connection. What does

    Bash
    curl http://ip-api.com | grep country

    say about the connection?

  • WireGuard VPN Manager

    That is a known issue with PIA. Dynamic, load-balanced auto-regions frequently establish a local connection link but fail to route internet traffic due to two infrastructure conflicts:

    • Virtual IP Assignment Conflict: These regions often enforce a static fallback placeholder (WireGuard.Address = 10.0.0.1/32). When ConnMan mounts this address locally, it conflicts directly with the remote server's internal gateway path. This confuses local routing tables and locks traffic into an infinite loop.
    • Un-Synchronized Gateway Balancers: Front-end balancers accept the cryptographic public key handshake and report a valid interface link status. However, they fail to sync the authentication session instantly down to the backend nodes handling live traffic. The local system brings up the wg0 interface, but the backend server drops data packets, resulting instantly network timeout.

    WireGuard Provider Architecture & Video Mapping Constraints


    But for the rest you can connect?


    Salute.

  • WireGuard VPN Manager

    The Libreelec info shows only the local network IP, the IP shown in WireGuard app is the IP from the server it connected to.

    In terminal (ssh) you can do:

    Bash
    curl http://ip-api.com | grep country

    This tells the country / region you connected to.

  • WireGuard VPN Manager

    Quote from Reddirt

    I disconnected and tried again:

    https://paste.libreelec.tv/jerkwater-keenan.log

    Shows connected but no connectivity. My test is speedtest to show new ip and speed but no connection.

    Code
    2026-05-30 19:00:57.068 T:2672     info <general>: CAddonMgr::FindAddon: service.wireguard.manager v1.4.6~beta.1 installed
2026-05-30 19:00:57.197 T:2778     info <general>: service.wireguard.manager v1.4.6~beta.1: Hardware timings loaded for Raspberry Pi 5
2026-05-30 19:00:57.197 T:2778     info <general>: service.wireguard.manager v1.4.6~beta.1: Monitor Service Initialized & Ready
2026-05-30 19:01:21.075 T:2676     info <general>: CAddonMgr::FindAddon: service.wireguard.manager v1.4.5 installed
2026-05-30 19:01:21.238 T:2829     info <general>: service.wireguard.manager v1.4.5: Hardware timings loaded for Raspberry Pi 5
2026-05-30 19:01:21.238 T:2829     info <general>: service.wireguard.manager v1.4.5: Monitor Service Initialized & Ready

    Did you uninstall v1.4.5 first? Because I see service.wireguard.manager v1.4.6~beta.1: installing (2026-05-30 19:00:57) and minute later service.wireguard.manager v1.4.5 getting installed again (2026-05-30 19:01:21).