I’ve got two RPI 3+ running DietPi on Buster. The only difference between the RPIs should be their hostname and IP addresses. But the other major difference is that RPI #1 doesn’t get issued an IPv6 and RPI #2 does. I’ve tried comparing as many config files as I can find and they look the same.
I’m pulling what’s left of my hair out. IPv6 is enabled for both in dietpi-config. Both /etc/network/interfaces files look like this:
# Location: /etc/network/interfaces
# Please modify network settings via: dietpi-config
# Or create your own drop-ins in: /etc/network/interfaces.d/
# Drop-in configs
source interfaces.d/*
# Loopback
auto lo
iface lo inet loopback
# Ethernet
allow-hotplug eth0
iface eth0 inet dhcp
address 192.168.1.106
netmask 255.255.255.0
gateway 192.168.1.1
#dns-nameservers 127.0.0.1
# WiFi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address 0.0.0.0
netmask 0.0.0.0
gateway 0.0.0.0
#dns-nameservers 0.0.0.0
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
With the only difference being the address line under #Ethernet (which shouldn’t really matter with DHCP anyway).
I’ve tried adding “iface eth0 inet6 dhcp” to RPI#1, but that doesn’t do anything – and RPI#2 doesn’t seem to need that line to get an IPv6 address.
RPI#1 does get a local IPv6 address (starting with fe80).
From RPI#2 I can ping RPI#1’s local IPv6:
RPI2# ping6 fe80::ba27:ebff:feb4:ffd4
PING fe80::ba27:ebff:feb4:ffd4(fe80::ba27:ebff:feb4:ffd4) 56 data bytes
64 bytes from fe80::ba27:ebff:feb4:ffd4%eth0: icmp_seq=1 ttl=64 time=0.711 ms
64 bytes from fe80::ba27:ebff:feb4:ffd4%eth0: icmp_seq=2 ttl=64 time=0.492 ms
64 bytes from fe80::ba27:ebff:feb4:ffd4%eth0: icmp_seq=3 ttl=64 time=0.655 ms
^C
--- fe80::ba27:ebff:feb4:ffd4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 71ms
rtt min/avg/max/mdev = 0.492/0.619/0.711/0.095 ms
However, RPI#1 cannot ping either RPI#2’s IPv6 addresses. One address does this:
RPI1# ping6 2601:601:c97f:d407:ba27:ebff:fe4a:a62c
connect: Network is unreachable
the other does:
RPI1# ping6 fe80::ba27:ebff:fe4a:a62c
PING fe80::ba27:ebff:fe4a:a62c(fe80::ba27:ebff:fe4a:a62c) 56 data bytes
and just hangs.
Any ideas?
Hi,
many thanks for your report. Pls can you try running the following
/boot/dietpi/func/dietpi-set_hardware enableipv6 enable
To verify assigned IP address you can use ip a
Have you enabled any firewall on the problematic Pi by any chance?
ip6tables-save -c
RPI1# /boot/dietpi/func/dietpi-set_hardware enableipv6 enable
DietPi-Set_hardware
─────────────────────────────────────────────────────
Mode: enableipv6 (enable)
[ OK ] DietPi-Set_hardware | Desired setting in /etc/hosts was already set: ::1 localhost ip6-localhost ip6-loopback
[ OK ] DietPi-Set_hardware | Desired setting in /etc/hosts was already set: ff02::1 ip6-allnodes
[ OK ] DietPi-Set_hardware | Desired setting in /etc/hosts was already set: ff02::2 ip6-allrouters
[ OK ] DietPi-Set_hardware | Desired setting in /boot/dietpi.txt was already set: CONFIG_ENABLE_IPV6=1
[ OK ] enableipv6 enable | Completed
Nope. 
Running “ip6tables-save -c” output is empty.
What does ip a gives back?
RPI1# ip a
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:xxxxxxx brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 65435sec preferred_lft 65435sec
inet6 fe80::ba27:ebff:feb4:ffd4/64 scope link
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::fa66:ff1d:67b1:2bc0/64 scope link stable-privacy
valid_lft forever preferred_lft forever
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.6.0.1/24 scope global wg0
valid_lft forever preferred_lft forever
looks like there is an IPv6 address assigned on eth0
inet6 fe80::ba27:ebff:feb4:ffd4/64
are you able to ping this address from your system themselves ?
That’s a self-assigned link-local address only (starts with fe80). It should also have a global one (which it receives from the router) starting with 2601, like the rest of the devices on this network segment – including the other RPI which SHOULD be a clone of the other that works.
RPI2 can ping RPI1’s link-local IPv6:
RPI2# ping6 fe80::ba27:ebff:feb4:ffd4
PING fe80::ba27:ebff:feb4:ffd4(fe80::ba27:ebff:feb4:ffd4) 56 data bytes
64 bytes from fe80::ba27:ebff:feb4:ffd4%eth0: icmp_seq=1 ttl=64 time=0.703 ms
64 bytes from fe80::ba27:ebff:feb4:ffd4%eth0: icmp_seq=2 ttl=64 time=0.657 ms
But RPI1 cannot ping RPI1’s link-local or global IPv6. It attempts to do on on link-local:
RPI1# ping6 fe80::ba27:ebff:fe4a:a62c
PING fe80::ba27:ebff:fe4a:a62c(fe80::ba27:ebff:fe4a:a62c) 56 data bytes
^C
--- fe80::ba27:ebff:fe4a:a62c ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 211ms
but complains that there’s no IPv6 network available at all if I try the global:
RPI1# ping6 2601:601:c97f:d407:ba27:ebff:fe4a:a62c
connect: Network is unreachable
I know it might be nonsense but what happen if you swap SD card between the 2 devices. Is the “issue” moving as well?