Jump to content

Antonio Mignolli

Members
  • Posts

    4
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Please, use chat GPT when you know exactly what you're doing With Type=oneshot Restart is NOT allowed. One shot services exit immediately, so "restart" makes no sense. Consider removing the post, it could lead to misinformation
  2. Hi all. I solved it, indeed, by "drastically" recompile wireguard-tools with a modification (makes sense, IMHO). https://github.com/WireGuard/wireguard-tools/pull/19 Basically, I am telling wireguard to keep trying reconnection according to configuration (environment variable WG_ENDPOINT_RESOLUTION_RETRIES), and don't modify this behaviour when some error types occur (EAI_NONAME or EAI_FAIL). I just noticed there is another modification, maybe even better, here: https://github.com/WireGuard/wireguard-tools/pull/18
  3. I recompiled armbian kernel, adding wireguard debug, but if wg-quick@ is not starting, nothing will be logged. It starts to print debug information when I manually restart it.
  4. Hi all, I am running armbian bookworm on a nanopi r6c (rk3588). At boot, wireguard does not resolve the endpoint (strange, because it runs after network-online.target) and instead of keep trying, it gives up. If I manually restart it, all is good. Attached screenshots show the different behaviour in a raspberry pi (rpi4 as hostname) running raspios, where it keeps trying to resolve the endpoint, and nanopi r6c not retrying. I will recompile kernel to enable wireguard debug (or is there a quicker way?)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines