BUG: Randomly fails

[Sommerwiesel]

trafficstars

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

[unixfox]

Was able to reproduce the issue again.

Jun 07 00:46:47 netcup-node02 systemd[1]: Started ipv6-rotation.service - "Rotate IPv6".
Jun 07 00:47:02 netcup-node02 python3[4122402]: [INFO] You have IPv6 connectivity. Continuing.
Jun 07 00:47:02 netcup-node02 python3[4122402]: [INFO] Finished cleaning up previous setup.
Jun 07 00:47:02 netcup-node02 python3[4122402]: [INFO] Waiting for the propagation in the Linux kernel.
Jun 07 00:47:02 netcup-node02 python3[4122402]: [DEBUG] Debug info:
Jun 07 00:47:02 netcup-node02 python3[4122402]: ranges --> ['2404:6800:4000::/36', '2607:f8b0:4000::/36', '2c0f:fb50:4000::/36', '2a00:1450:4000::/36', '2800:3f0:4000::/36', '2001:4860:4000::/36']
Jun 07 00:47:02 netcup-node02 python3[4122402]: random_ipv6_address --> 2a0a:4cc0:1:11a2:ffd4:81b6:1e68:6f24
Jun 07 00:47:02 netcup-node02 python3[4122402]: gateway --> fe80::1
Jun 07 00:47:02 netcup-node02 python3[4122402]: interface_index --> 2
Jun 07 00:47:02 netcup-node02 python3[4122402]: interface_name --> eth0
Jun 07 00:47:02 netcup-node02 python3[4122402]: ipv6_subnet --> 2a0a:4cc0:1:11a2::/64
Jun 07 00:47:02 netcup-node02 python3[4122402]: random_ipv6_address_mask --> 64
Jun 07 00:47:02 netcup-node02 python3[4122402]: [Error]  Failed to remove the configured IPv6 subnets 2404:6800:4000::/36,2607:f8b0:4000::/36,2c0f:fb50:4000::/36,2a00:1450:4000::/36,2800:3f0:4000::/36,2001:4860:4000::/36
Jun 07 00:47:02 netcup-node02 python3[4122402]:             May be expected if the route were not yet configured and that was a cleanup due to an error
Jun 07 00:47:02 netcup-node02 python3[4122402]:             
Jun 07 00:47:02 netcup-node02 python3[4122402]: [INFO] Finished cleaning up previous setup.
Jun 07 00:47:02 netcup-node02 python3[4122402]: [INFO] Waiting for the propagation in the Linux kernel.
Jun 07 00:47:02 netcup-node02 python3[4122402]: [Error] Failed to configure the test IPv6 route. The setup did not work!
Jun 07 00:47:02 netcup-node02 python3[4122402]:        Exception:
Jun 07 00:47:02 netcup-node02 python3[4122402]: (22, 'Invalid argument')
Jun 07 00:47:02 netcup-node02 systemd[1]: ipv6-rotation.service: Main process exited, code=exited, status=1/FAILURE

[unixfox]

A new parameter has been added: --cron: https://github.com/iv-org/smart-ipv6-rotator/pull/25

This will essentially disable the HTTP checks after the ipv6 address is configured.

It is the recommended parameter when using the script with CRON.