Network | Skip IPv6 check on missing GUA instead of missing gateway

taoteh1221 commented 1 year ago

Creating a bug report/issue

Required Information

DietPi version |
G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=14 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_LIVE_PATCH_STATUS[0]='not applicable'
Distro version |
bullseye
Kernel version |
Linux zero 6.0.13-meson64 #22.11.2 SMP PREEMPT Sun Dec 18 16:52:19 CET 2022 aarch64 GNU/Linux
SBC model |
Radxa Zero (aarch64)
Power supply used
25 watt USB-C
SD card used |
SanDisk ultra 64gb

Additional Information (if applicable)

FRESH INSTALL OF: DietPi_RadxaZero-ARMv8-Bullseye.img ( downloaded 2023/2/15, from https://dietpi.com/docs/hardware/#radxa )

WIFI ROUTER: Netgear RAX20

Steps to reproduce

/boot/dietpi-wifi.txt setup properly with SSID / KEY

/boot/dietpi.txt NETWORKING SETUP BEFORE FIRST BOOT:

AUTO_SETUP_LOCALE=en_US.UTF-8

AUTO_SETUP_KEYBOARD_LAYOUT=us

AUTO_SETUP_TIMEZONE=America/New_York

AUTO_SETUP_NET_ETHERNET_ENABLED=1

AUTO_SETUP_NET_WIFI_ENABLED=1

AUTO_SETUP_NET_ETH_FORCE_SPEED=0

AUTO_SETUP_NET_WIFI_COUNTRY_CODE=US

AUTO_SETUP_NET_USESTATIC=0 AUTO_SETUP_NET_STATIC_IP=192.168.0.100 AUTO_SETUP_NET_STATIC_MASK=255.255.255.0 AUTO_SETUP_NET_STATIC_GATEWAY=192.168.0.1 AUTO_SETUP_NET_STATIC_DNS=9.9.9.9 149.112.112.112

AUTO_SETUP_DHCP_TO_STATIC=0

AUTO_SETUP_NET_HOSTNAME=zero

AUTO_SETUP_BOOT_WAIT_FOR_NETWORK=1

CONFIG_ENABLE_IPV6=1

Expected behaviour

Pre-configured wifi should connect on first boot without issues.

...

Actual behaviour

Wifi will NOT connect, until ipv6 is disabled.

...

Extra details

I used dietpi-config with a wired keyboard / display to diagnose and fix the issue.

taoteh1221 commented 1 year ago

I probably should clarify:

CONFIG_ENABLE_IPV6=1 was the default setting, I did NOT modify it in the /boot/dietpi.txt file.

MichaIng commented 1 year ago

Thanks for your report. I'm however pretty sure its an issue with your network not (reliably) supporting IPv6, rather than an issue with the WiFi chip or driver of the Radxa Zero. It's a WiFi-only device and there are around 200 - 300 instances running DietPi which were able to upload a survey file, hence had Internet access.

But to better know why it fails in your case, we'd need some more details, like what you mean with "Wifi will NOT connect", at which point it fails, which messages/errors you see. Also the following output will be helpful, when booting with IPv6 enabled:

journalctl -u ifup@wlan0
ip a
ip r
ip -6 r

taoteh1221 commented 1 year ago

Thanks for your report. I'm however pretty sure its an issue with your network not (reliably) supporting IPv6, rather than an issue with the WiFi chip or driver of the Radxa Zero. It's a WiFi-only device and there are around 200 - 300 instances running DietPi which were able to upload a survey file, hence had Internet access.

Your welcome. The last fresh install of Dietpi I did on this device (roughly a few weeks ago), I indeed had NO CONNECTION ISSUES running first-boot wifi setup (using the same wifi router with no changes to it). I was kinda presuming you had just added ipv6 to dietpi.txt in the download image I got on your website on 2023/2/15?

I'm running some tests today for and end user of my own open source releases, but Sunday 2/19 I will enable ipv6 on the zero and give you the output of the commands you mentioned, as well as document in detail my attempts connecting to wifi with dietpi-config.

ADDITIONALLY, I just quickly checked my wifi router's ipv6 status, and it looks like ipv6 is "not available" (see attached screenshot): Selection_016

Joulinar commented 1 year ago

IPv6 is available long time already. The toggle CONFIG_ENABLE_IPV6=1 has been added in DietPi v6.17 https://github.com/MichaIng/DietPi/commit/c6c4238b885911b3709ce56c96c5f3338b2114e0.

You would need to disable IPv6 if not supported inside your network.

MichaIng commented 1 year ago

Actually there is some fallback if IPv6 is not available at all on the network (no GUA and route assigned), which is likely the reason it didn't cause issues before. It is obviously not reliable, also shown by many other cases where IPv6 needs to be disabled, but probably the command's outputs will give some hint.

taoteh1221 commented 1 year ago

So I tried to replicate the issue by re-enabling ipv6 on the radxa zero as show below (this is the same method I used to disable it originally):

"sudo dietpi-config => 7 : Network Options: Adapters => IPv6" == On

I rebooted, BUT THIS TIME I still had wifi connectivity just fine, ZERO issues:


dietpi@zero:~$ ping google.com
PING google.com (172.217.13.110) 56(84) bytes of data.
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=1 ttl=117 time=46.8 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=2 ttl=117 time=49.9 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=3 ttl=117 time=57.2 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=4 ttl=117 time=60.3 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=5 ttl=117 time=51.6 ms
^C
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 46.767/53.166/60.340/4.921 ms
dietpi@zero:~$

Here are the outputs of the commands you wanted:

'sudo journalctl -u ifup@wlan0' output:

-- Journal begins at Sun 2023-02-19 14:27:42 EST, ends at Sun 2023-02-19 14:35:54 EST. --
Feb 19 14:27:44 zero systemd[1]: Starting ifup for wlan0...
Feb 19 14:27:44 zero wpa_supplicant[1044]: Successfully initialized wpa_supplicant
Feb 19 14:27:45 zero dhclient[1096]: Internet Systems Consortium DHCP Client 4.4.1
Feb 19 14:27:45 zero ifup[1096]: Internet Systems Consortium DHCP Client 4.4.1
Feb 19 14:27:45 zero ifup[1096]: Copyright 2004-2018 Internet Systems Consortium.
Feb 19 14:27:45 zero ifup[1096]: All rights reserved.
Feb 19 14:27:45 zero ifup[1096]: For info, please visit https://www.isc.org/software/dhcp/
Feb 19 14:27:45 zero dhclient[1096]: Copyright 2004-2018 Internet Systems Consortium.
Feb 19 14:27:45 zero dhclient[1096]: All rights reserved.
Feb 19 14:27:45 zero dhclient[1096]: For info, please visit https://www.isc.org/software/dhcp/
Feb 19 14:27:45 zero dhclient[1096]: 
Feb 19 14:27:45 zero dhclient[1096]: Listening on LPF/wlan0/20:50:e7:1a:25:59
Feb 19 14:27:45 zero ifup[1096]: Listening on LPF/wlan0/20:50:e7:1a:25:59
Feb 19 14:27:45 zero ifup[1096]: Sending on   LPF/wlan0/20:50:e7:1a:25:59
Feb 19 14:27:45 zero ifup[1096]: Sending on   Socket/fallback
Feb 19 14:27:45 zero ifup[1096]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
Feb 19 14:27:45 zero dhclient[1096]: Sending on   LPF/wlan0/20:50:e7:1a:25:59
Feb 19 14:27:45 zero dhclient[1096]: Sending on   Socket/fallback
Feb 19 14:27:45 zero dhclient[1096]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
Feb 19 14:27:45 zero wpa_supplicant[1091]: wlan0: Trying to associate with SSID 'linksys77_guest'
Feb 19 14:27:46 zero wpa_supplicant[1091]: wlan0: Associated with 6a:36:c9:fc:fd:11
Feb 19 14:27:46 zero wpa_supplicant[1091]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Feb 19 14:27:46 zero wpa_supplicant[1091]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
Feb 19 14:27:46 zero wpa_supplicant[1091]: wlan0: WPA: Key negotiation completed with 6a:36:c9:fc:fd:11 [PTK=CCMP GTK=CCMP]
Feb 19 14:27:46 zero wpa_supplicant[1091]: wlan0: CTRL-EVENT-CONNECTED - Connection to 6a:36:c9:fc:fd:11 completed [id=0 id_str=]
Feb 19 14:27:53 zero dhclient[1096]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
Feb 19 14:27:53 zero ifup[1096]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
Feb 19 14:27:53 zero dhclient[1096]: DHCPOFFER of 192.168.1.27 from 192.168.1.1
Feb 19 14:27:53 zero ifup[1096]: DHCPOFFER of 192.168.1.27 from 192.168.1.1
Feb 19 14:27:53 zero ifup[1096]: DHCPREQUEST for 192.168.1.27 on wlan0 to 255.255.255.255 port 67
Feb 19 14:27:53 zero dhclient[1096]: DHCPREQUEST for 192.168.1.27 on wlan0 to 255.255.255.255 port 67
Feb 19 14:27:53 zero dhclient[1096]: DHCPACK of 192.168.1.27 from 192.168.1.1
Feb 19 14:27:53 zero ifup[1096]: DHCPACK of 192.168.1.27 from 192.168.1.1
Feb 19 14:27:53 zero dhclient[1096]: bound to 192.168.1.27 -- renewal in 851 seconds.
Feb 19 14:27:53 zero ifup[1096]: bound to 192.168.1.27 -- renewal in 851 seconds.
Feb 19 14:27:53 zero systemd[1]: Finished ifup for wlan0.

'ip a' output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 20:50:e7:1a:25:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.27/24 brd 192.168.1.255 scope global dynamic wlan0
       valid_lft 1333sec preferred_lft 1333sec
    inet6 fe80::2250:e7ff:fe1a:2559/64 scope link 
       valid_lft forever preferred_lft forever

'ip r' output:

default via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.27 

'ip -6 r' output:

::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
default via fe80::a36:c9ff:fefc:fd10 dev wlan0 proto ra metric 1024 expires 1599sec hoplimit 64 pref low

I still have the same disk image I downloaded on 2023/2/15, so I could try a new fresh install, and run the commands on that BEFORE disabling ipv6 (presuming the same issue arises a second time around). I'll give that a try on monday 2/20, and let you know how it goes. Interesting that turning ipv6 on after turning off does NOT recreate the issue.

MichaIng commented 1 year ago

Interesting. Still no GUA (expectedly) but the router does promote itself as default IPv6 gateway, which has no point then 😄. However, at least in this situation the IPv4 fallback seems to work, since google.com is pingged via IPv4 now.

You see the 1599sec in your last output? If the router is not regularly refreshing that route, it will expire. Would be interesting if the fallback does NOT work anymore if no default route is there. Would be highly confusing, but that is what we found IPv6 to be.

Another problem is that with an IPv6 default route, our network connection check will test IPv6 as well, which is doomed to fail for a remote host. It is complete nonsense for a router to assign a gateway without a routable IP address, but this is what it is here, and there doesn't even seem to be a way to disable this in router settings. If this is more common, we need to not (only) check for a default route, but for a GUA instead. Best would be if we could find out exactly in which case the system does an IPv4 fallback automatically, and skip the IPv6 check exactly in this case.

taoteh1221 commented 1 year ago

I wrote a quick bash script that writes the outputs you wanted to file, so I'll copy this script to my fresh image tomorrow, set my wifi configs in /boot/ but leave ipv6 enabled, and see what we get. Hopefully it re-creates the issue I had, and shows 'a different story' in those command outputs.

taoteh1221 commented 1 year ago

FIRST OFF, BUG REPORT FILED FROM DEVICE:


[  OK  ] DietPi-BugReport | Checking IPv6 network connectivity
[  OK  ] DietPi-BugReport | Packing upload archive
[  OK  ] DietPi-BugReport | Sending bug report
[  OK  ] DietPi-BugReport | Your bug report has been successfully uploaded.
- Reference code: 5aa32a75-8551-4fa9-ab3d-17dce83a626c

Ok, so it looks like your 'auto-setup' first run command may be an ipv6 ping, and the setup screen 'error message' won't go away unless I CHOOSE "Disable IPV6", BUT ipv4 ping DOES WORK. So it was just a kinda confusing user experience...EVERYTHING WENT SMOOTHLY AFTER DISABLING IPV6 (details / logs below).

The PREVIOUS fresh install I did, my ADDITIONAL ISSUE was I could NOT connect remotely via SSH until IPv6 was disabled (I was troubleshooting on the attached TINY 7" LCD with a USB keyboard, SO I COMPLETELY MISSED READING IT WAS AN IPV6 PING FAILURE, AND WENT STRAIGHT TO "NETWORK SETTINGS" FIRST). This time that was NOT the case, WIFI CONNECTED FINE from the automated /boot/dietpi* files, and I was able to SSH in immediately after boot (EVEN THOUGH IPV6 WAS STILL ENABLED).

For end-user UX, it might be a good idea to run an IPv4 ping automatically after IPv6 failure, and alert the end-user that disabling IPv6 is recommended (or alert them it has been disabled after auto-disabling)? Without adding that kind of UX logic, an end-user is stuck on this screen until they figure things out on their own (or are on a big enough screen to easily read the top section is reporting the exact error):

Selection_017

FIRST LOGIN inputs / outputs (BEFORE DISABLING IPV6):


The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
 ─────────────────────────────────────────────────────
 DietPi v8.14.2 : 14:58 - Mon 02/20/2023
 ─────────────────────────────────────────────────────
 - LAN IP : 192.168.1.27 (wlan0)

 DietPi-Update
─────────────────────────────────────────────────────
 Phase: Checking for available DietPi update

[  OK  ] DietPi-Update | Checking IPv4 network connectivity
[FAILED] DietPi-Update | Checking IPv6 network connectivity
 - Command: ping -6nc 1 -W 10 2620:fe::fe

---------------------------------------------------------------------
- DietPi has encountered an error                                   -
- Please create a ticket: https://github.com/MichaIng/DietPi/issues -
- Copy and paste only the BLUE lines below into the ticket          -
---------------------------------------------------------------------
#### Details:
- Date           | Mon Feb 20 14:58:19 EST 2023
- DietPi version | v8.14.2 (MichaIng/master)
- Image creator  | DietPi Core Team
- Pre-image      | from scratch
- Hardware       | Radxa Zero (aarch64) (ID=74)
- Kernel version | `Linux zero 6.0.13-meson64 #22.11.2 SMP PREEMPT Sun Dec 18 16:52:19 CET 2022 aarch64 GNU/Linux`
- Distro         | bullseye (ID=6)
- Command        | `ping -6nc 1 -W 10 2620:fe::fe`
- Exit code      | 1
- Software title | DietPi-Update
#### Steps to reproduce:
<!-- Explain how to reproduce the issue -->
1. ...
2. ...
#### Expected behaviour:
<!-- What SHOULD happen? -->
- ...
#### Actual behaviour:
<!-- What IS happening? -->
- ...
#### Extra details:
<!-- Please post any extra details that might help solve the issue -->
- ...
#### Additional logs:

PING 2620:fe::fe(2620:fe::fe) 56 data bytes
From fe80::a36:c9ff:fefc:fd10%wlan0 icmp_seq=1 Destination unreachable: No route

--- 2620:fe::fe ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

---------------------------------------------------------------------
[FAILED] DietPi-Update | Unable to continue, DietPi-Update will now terminate.
 ─────────────────────────────────────────────────────
 DietPi v8.14.2 : 14:58 - Mon 02/20/2023
 ─────────────────────────────────────────────────────
 - LAN IP : 192.168.1.27 (wlan0)
[  OK  ] DietPi-Login | Desired setting in /boot/dietpi.txt was already set: AUTO_SETUP_AUTOMATED=0
root@zero:~# ping google.com > pingtest.txt
root@zero:~# ./ipv6testing.bash

IPV4 PING TEST LOGGED IN AS ROOT, FIRST RUN (BEFORE DISABLING IPV6):


PING google.com (172.217.13.110) 56(84) bytes of data.
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=1 ttl=117 time=51.1 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=2 ttl=117 time=54.5 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=3 ttl=117 time=52.6 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=4 ttl=117 time=52.1 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=5 ttl=117 time=66.3 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=6 ttl=117 time=64.4 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=7 ttl=117 time=66.4 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=8 ttl=117 time=52.8 ms
64 bytes from yul02s04-in-f14.1e100.net (172.217.13.110): icmp_seq=9 ttl=117 time=55.6 ms

--- google.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8013ms
rtt min/avg/max/mdev = 51.109/57.298/66.353/6.068 ms

journalctl / ip COMMAND OUTPUTS LOGGED IN AS ROOT, FIRST RUN (BEFORE DISABLING IPV6):


'journalctl -u ifup@wlan0' output:

-- Journal begins at Mon 2023-02-13 17:39:34 EST, ends at Mon 2023-02-20 14:58:18 EST. --
-- No entries --

'ip a' output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 20:50:e7:1a:25:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.27/24 brd 192.168.1.255 scope global dynamic wlan0
       valid_lft 1461sec preferred_lft 1461sec
    inet6 fe80::2250:e7ff:fe1a:2559/64 scope link
       valid_lft forever preferred_lft forever

'ip r' output:

default via 192.168.1.1 dev wlan0
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.27

'ip -6 r' output:

::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
default via fe80::a36:c9ff:fefc:fd10 dev wlan0 proto ra metric 1024 expires 1440sec hoplimit 64 pref low

MichaIng commented 1 year ago

Yes all expected, as I said

Another problem is that with an IPv6 default route, our network connection check will test IPv6 as well, which is doomed to fail for a remote host.

If you wait for the 1440 seconds (whichever value shown on ip -6 r) for the route to expire, is it renewed in between to that the timer resets to 1800 seconds regularly?

And does this work?

ip -6 r del default
ping dietpi.com

taoteh1221 commented 1 year ago

I'm back to running the image install from 2023/2/15, with ipv6 enabled again, and now everything reports OK on a dietpi-config connection test in this screenshot:

Selection_020

I'm not familiar with ipv6 or resets on expiring network params, but I'm guessing from this output that it is renewing:

dietpi@zero:~$ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
default via fe80::a36:c9ff:fefc:fd10 dev wlan0 proto ra metric 1024 expires 1628sec hoplimit 64 pref low

Output looks OK for the command (before pinging) that you mentioned as well:

dietpi@zero:~$ sudo ip -6 r del default
dietpi@zero:~$ ping dietpi.com
PING dietpi.com (172.67.170.219) 56(84) bytes of data.
64 bytes from 172.67.170.219 (172.67.170.219): icmp_seq=1 ttl=55 time=46.9 ms
64 bytes from 172.67.170.219 (172.67.170.219): icmp_seq=2 ttl=55 time=48.3 ms
64 bytes from 172.67.170.219 (172.67.170.219): icmp_seq=3 ttl=55 time=54.4 ms
64 bytes from 172.67.170.219 (172.67.170.219): icmp_seq=4 ttl=55 time=56.8 ms
64 bytes from 172.67.170.219 (172.67.170.219): icmp_seq=5 ttl=55 time=59.7 ms
^C
--- dietpi.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 46.856/53.228/59.739/4.931 ms
dietpi@zero:~$

MichaIng commented 1 year ago

now everything reports OK on a dietpi-config on a dietpi-config connection test in this screenshot

As long as the fallback to IPv4 works, connections work, but the DietPi network connection check done in front of DietPi updates and software installs would still fail on IPv6 as long as the default route is active. If that passed, then the route did not exist at the time the check ran.

Good that the fallback stays active after removing the route. I need to run some tests but it then looks like the fallback is done as long as no GUA is applied, probably not ULA (Unique Local Address, like a local IP for IPv6) must be applied either.

taoteh1221 commented 1 year ago

Good luck tweaking the UX just right, holler if you need anything else.

MichaIng commented 1 year ago

Okay, it seems to be the automatic fallback is done in both cases: if either the default route or the GUA (or both) are missing:

root@VM-Bullseye:~# curl -sIv https://dns9.quad9.net 2>&1 | grep Trying; ping -nc 1 dns9.quad9.net | grep '(.*)'
*   Trying 2620:fe::9:443...
PING dns9.quad9.net(2620:fe::fe:9) 56 data bytes
root@VM-Bullseye:~# ip -6 a del dev eth0 2a01:myGUA/64
root@VM-Bullseye:~# curl -sIv https://dns9.quad9.net 2>&1 | grep Trying; ping -nc 1 dns9.quad9.net | grep '(.*)'
*   Trying 9.9.9.9:443...
PING dns9.quad9.net (149.112.112.9) 56(84) bytes of data.
root@VM-Bullseye:~# ip -6 a add dev eth0 2a01:myGUA/64
root@VM-Bullseye:~# curl -sIv https://dns9.quad9.net 2>&1 | grep Trying; ping -nc 1 dns9.quad9.net | grep '(.*)'
*   Trying 2620:fe::9:443...
PING dns9.quad9.net(2620:fe::fe:9) 56 data bytes
root@VM-Bullseye:~# ip -6 r del default
root@VM-Bullseye:~# curl -sIv https://dns9.quad9.net 2>&1 | grep Trying; ping -nc 1 dns9.quad9.net | grep '(.*)'
*   Trying 9.9.9.9:443...
PING dns9.quad9.net (149.112.112.9) 56(84) bytes of data.
root@VM-Bullseye:~# ip -6 r add dev eth0 default via fe80::7edb:98ff:fe93:c035
root@VM-Bullseye:~# curl -sIv https://dns9.quad9.net 2>&1 | grep Trying; ping -nc 1 dns9.quad9.net | grep '(.*)'
*   Trying 2620:fe::9:443...
PING dns9.quad9.net(2620:fe::fe:9) 56 data bytes
root@VM-Bullseye:~# ip -6 r del default
root@VM-Bullseye:~# ip -6 a del dev eth0 2a01:myGUA/64
root@VM-Bullseye:~# curl -sIv https://dns9.quad9.net 2>&1 | grep Trying; ping -nc 1 dns9.quad9.net | grep '(.*)'
*   Trying 9.9.9.9:443...
PING dns9.quad9.net (149.112.112.9) 56(84) bytes of data.

Tested also on Buster and Bookworm. So we must only do the IPv6 check if both, the route and a GUA, are present. Why there is a space in dns9.quad9.net (149.112.112.9) but not in dns9.quad9.net(2620:fe::fe:9)? 🤔 ... no matter 😄

I was wondering how to differentiate GUA and ULA since both have global scope and appear identical:

root@micha:~# ip -6 a s scope global
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fdb3:6885:c596:0:ba27:ebff:fe1c:6a6d/64 scope global dynamic mngtmpaddr
       valid_lft 5542sec preferred_lft 1942sec
    inet6 2a01:myGUA/64 scope global dynamic mngtmpaddr
       valid_lft 216806sec preferred_lft 130406sec

But we know the ULA address range, so:

root@micha:~# ip -6 -br a s to 2000::/3
eth0             UP             2a01:myGUA/64
root@micha:~# ip -6 -br a s to fc00::/7
eth0             UP             fdb3:6885:c596:0:ba27:ebff:fe1c:6a6d/64

MichaIng commented 1 year ago

Done with: https://github.com/MichaIng/DietPi/commit/ddf2787

taoteh1221 commented 1 year ago

Done with: ddf2787

Sweet! :)

MichaIng / DietPi