BUG: Randomly fails

[Sommerwiesel]

The script (executed as root) randomly fails. If I manually execute it again after if failed (or during next cron execution) it seems to work again.

Debug output:

[INFO] You have IPv6 connectivity. Continuing.
[INFO] Finished cleaning up previous setup. [INFO] Waiting for the propagation in the Linux kernel.
[DEBUG] Debug info:
random_ipv6_address --> 2a01:4f8:200:33ee:ac3c:270:da01:29ae
random_ipv6_address_mask --> 64
gateway --> fe80::1
interface_index --> 2
interface_name --> eno1
ipv6_subnet --> 2a01:4f8:200:33ee::/64
[Error] Failed to remove the test IPv6 subnet.
May be expected if the route were not yet configured and that was a cleanup due to an error.
[Error] Failed to remove the configured (Google) IPv6 subnets.
May be expected if the route were not yet configured and that was a cleanup due to an error.
[INFO] Finished cleaning up previous setup.
[INFO] Waiting for the propagation in the Linux kernel.
[Error] Failed to configure the test IPv6 route. The setup did not work!
Exception:
(22, 'Invalid argument')

Next execution:

[INFO] You have IPv6 connectivity. Continuing.
[INFO] No cleanup of previous setup needed.
[DEBUG] Debug info:
random_ipv6_address --> 2a01:4f8:200:33ee:f769:b034:af7b:8fd1
random_ipv6_address_mask --> 64
gateway --> fe80::1
interface_index --> 2
interface_name --> eno1
ipv6_subnet --> 2a01:4f8:200:33ee::/64
[INFO] Correctly using the new random IPv6 address, continuing.
[INFO] Correctly configured the IPv6 routes for Google IPv6 ranges.
[INFO] Successful setup. Waiting for the propagation in the Linux kernel.

[Sommerwiesel]

Three days without happening again, probably a temporary problem, probably not due to your script but the servers network acting up (Hetzner maintenance maybe?)

Leaving open as to your request.

[unixfox]

Closing as I didn't found anything that could create this bug.

[r2fo]

I have also been experiencing this bug for a few days.

I have enabled cronjob logging and found that it randomly errors out on some occasions. I thought about running 2 cronjobs of it a minute after each other. If the first one errors out, the second one will fix it, but the problem now is that if the first one works successfully, the second one will fail. So I reverted that change.

Sat Dec  9 12:00:01 AM CET 2023 [INFO] You have IPv6 connectivity. Continuing.
[INFO] Finished cleaning up previous setup.
[INFO] Waiting for the propagation in the Linux kernel.
[DEBUG] Debug info:
random_ipv6_address --> 2a03:REDACTED
random_ipv6_address_mask --> 64
gateway --> fe80::1
interface_index --> 2
interface_name --> eth0
ipv6_subnet --> 2a03:REDACTED/64
[INFO] Correctly using the new random IPv6 address, continuing.
[INFO] Correctly configured the IPv6 routes for Google IPv6 ranges.
[INFO] Successful setup. Waiting for the propagation in the Linux kernel.

Sat Dec  9 12:00:01 PM CET 2023 [INFO] You have IPv6 connectivity. Continuing.
[INFO] Finished cleaning up previous setup.
[INFO] Waiting for the propagation in the Linux kernel.
[DEBUG] Debug info:
random_ipv6_address --> 2a03:REDACTED
random_ipv6_address_mask --> 64
gateway --> fe80::1
interface_index --> 2
interface_name --> eth0
ipv6_subnet --> 2a03:REDACTED/64
[Error] Failed to remove the test IPv6 subnet.
        May be expected if the route were not yet configured and that was a cleanup due to an error.
[Error] Failed to remove the configured (Google) IPv6 subnets.
        May be expected if the route were not yet configured and that was a cleanup due to an error.
[INFO] Finished cleaning up previous setup.
[INFO] Waiting for the propagation in the Linux kernel.

[unixfox]

@r2fo
Can you reproduce the issue if you use another ipv6 docker network?
Like

networks:
  default:
    enable_ipv6: true
    ipam:
      config:
        - subnet: fd01:db8:a::/64
          gateway: fd01:db8:a::1

[r2fo]

@r2fo

Can you reproduce the issue if you use another ipv6 docker network?

Like

networks:

  default:

    enable_ipv6: true

    ipam:

      config:

        - subnet: fd01:db8:a::/64

          gateway: fd01:db8:a::1

In the Matrix server, I read that subnet: fd01:db8:a::/64 and gateway: fd01:db8:a::1 favor IPv4 over IPv6. And I was told to use 2001:0DB8::/112 so that Docker would prefer IPv6

https://matrix.to/#/!EgLVqODCMqgvSrNDkS%3Amatrix.org/%247Hq-BLhGJAjGDD1brGzkBftj3bsvcqLch8HR2quYGGA

[unixfox]

Sure but if you are using invidious this does not matter a lot with the parameter "force_resolve".

[r2fo]

Sure but if you are using invidious this does not matter a lot with the parameter "force_resolve".

I'm sorry, I forgot to mention I'm using Piped

[unixfox]

Who is your server provider @r2fo?

[r2fo]

Netcup

Edit: increasing the delays in the script from 2 seconds to 4 seconds and the curl timeout from 5 seconds to 10 seconds seems to have improved the success rate

[unixfox]

Please test with the latest code update. Do a clean before upgrading: https://github.com/iv-org/smart-ipv6-rotator?tab=readme-ov-file#upgrading