No IPv6 on DietPi with SLAAC

[Zelaf]

That did it!

Perhaps there should be a reboot prompt?

[Joulinar]

Usually there is. Will check it later on my RPi4. Maybe the UI experience is not that optimal.

[MichaIng]

@Zelaf

This website works for me and since my global link from SLAAC is the same but with a longer prefix it shows the full MAC as well if I just make it a local address instead.

Ah thanks, now I see it as well. Was looking wrong somehow. So yeah, the part of the GUA behind the prefix is identical to the LLA (after fe80::), containing the full MAC. I wasn’t aware of that, indeed a privacy issue .

@Zelaf

IPv6 Subnet I think is just an IPv4 Subnet but for IPv6 addresses from what I understand of it so while you can set longer prefix there and have another subnet and add routing to it you can also change the DHCPv6 prefix by adding to it, for example, be55:db35:c602:5ab9::/56 suffix for the dedicated range to your local network you can do the delegation address of be55:db35:c602:5ab9:dead:beef::/64.

It is clear what a “subnet” is, but not sure what a “subnet ID” is. Also this setting is independent of DHCPv6, so I assume, whatever it does, it works with SLAAC as well. Ah, some web search gives the answer: Cisco Learning Network
So the “ID” is the 16 bits behind the prefix (which I cannot change for the ULA in my case), just as you said .

[Zelaf]

So I installed hostapd again through the hotspot app and afterwards I don’t get IPv6 anymore through SLAAC at all. For now I could enable it by adding it through ip addr and ip route.

@MichaIng @trendy How would you suggest I troubleshoot further to see what the hotspot is doing?

[MichaIng]

@Zelaf

through the hotspot app

Do you mean the dietpi-software WiFi hotspot install option?

Is accept_ra set to 2 now for all interfaces?

sysctl -a | grep 'accept_ra '

Else try:

sysctl net.ipv6.conf.default.accept_ra=2 net.ipv6.conf.all.accept_ra=2

This is however done as part of the WiFi hotspot installation, along with a related config file /etc/sysctl.d/dietpi-wifihotspot.conf to set this automatically at boot.

[Zelaf]

@MichaIng

Is accept_ra set to 2 now for all interfaces?

~$ sudo sysctl -a | grep 'accept_ra '
net.ipv6.conf.all.accept_ra = 2
net.ipv6.conf.br-7ae53c7f8e4e.accept_ra = 0
net.ipv6.conf.br-b7aac2199e04.accept_ra = 0
net.ipv6.conf.default.accept_ra = 2
net.ipv6.conf.docker0.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.lo.accept_ra = 1
net.ipv6.conf.veth1408172.accept_ra = 2
net.ipv6.conf.veth155f384.accept_ra = 2
net.ipv6.conf.veth6ade40e.accept_ra = 2
net.ipv6.conf.veth6dab4d2.accept_ra = 2
net.ipv6.conf.veth8067cf0.accept_ra = 2
net.ipv6.conf.veth93733a8.accept_ra = 2
net.ipv6.conf.veth9ecb3c9.accept_ra = 2
net.ipv6.conf.vethc980e81.accept_ra = 2
net.ipv6.conf.vethe4095b7.accept_ra = 2
net.ipv6.conf.wlan0.accept_ra = 2

Seems like it’s 1 on eth0, and 2 on wlan0, will it cause complications if I disable it on wlan0 since I don’t need IPv6 on that interface and put it on 2 for eth0?

dietpi-wifihotspot.conf

net.ipv4.ip_forward=1
net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1

I’m guessing I should edit it in this file if I want to change that.

Right now I’ve enabled the hotspot and rebooted but don’t get any network on it anyways weirdly enough.

[trendy]

the net.ipv6.ip_forward will be 1 so you need to have accept_ra set to 2 for the eth0 at least to get the RAs. For the wlan you don’t need it enabled at all, as you don’t expect RAs.

[Zelaf]

Seemed to have worked flawlessy thank you!

Now I need to figure out why the devices are not getting a connection.

Edit:
Getting this in the journalctl logs:

No subnet declaration for wlan0 (no IPv4 addresses).
** Ignoring requests on wlan0.  If this is not what
   you want, please write a subnet declaration
   in your dhcpd.conf file for the network segment
   to which interface wlan0 is attached. **
Not configured to listen on any interfaces!
If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging.
exiting.

Edit 2:
ifup wlan0 and service isc-dhcp-server start fixed it.

[Joulinar]

@Zelaf

Edit 2:
ifup wlan0 and service isc-dhcp-server start fixed it.

how does it behave after reboot? All working fine still?

[Zelaf]

Yeah it did, all seems to work fine now on the IPv6 RA part now!

[Zelaf]

Is there a way to block the subnet to talk to the rest of the eth0 LAN but enable them to talk to a few devices? Was gonna block the traffic between the hotspot and the LAN except to my phone to allow it to talk to the IoT devices

[trendy]

Yes, with firewall rules.

[Zelaf]

Sorry to revive an old thread but I’m weirdly getting the same issue again after installing Tailscale, I’ve setup an external AP for my network now so no more AP needed from DietPi but after installing the Tailscale package I curiously am not getting IPv6 again.

I’ve reviewed the thread but and made sure that the accept_ra is set to 2 but still get nothing, here’s my current dietpi-tailscale.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.accept_ra = 2

[trendy]

Have you verified with:
sudo sysctl -a | grep 'accept_ra '
that everything is correct and no other script is interfering?

[Zelaf]

Sorry for the late reply.

$ sudo sysctl -a | grep 'accept_ra '
net.ipv6.conf.all.accept_ra = 2
net.ipv6.conf.default.accept_ra = 2
net.ipv6.conf.docker0.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.lo.accept_ra = 1
net.ipv6.conf.tailscale0.accept_ra = 2

Interestingly eth0 is on 1, I’ll see if I can dig around for config files, where would be the best to look? From what I can see all the config files in /etc/sysctl.d don’t have any config options for the net.ipv6.conf except dietpi-tailscale.conf where I did change or add net.ipv6.conf.eth0.accept_ra = 2.

Edit:
I edited the dietpi-tailscale.conf and removed the space around the equal sign and now I get the output:

$ cat dietpi-tailscale.conf
net.ipv4.ip_forward=1
net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.accept_ra=2

Curious how it shows with a space when doing the sysctl command but doesn’t like it in the config file but I at least learnt to double check syntaxing of config files in the future!

Now I just need to figure out how to force an IP update without restarting the Pi, I still don’t get one after doing systemctl restart networking.

[trendy]

How about ifup eth0 ?

[Zelaf]

Curiously the ra setting was reset back to 1…

$ sudo sysctl -a | grep net.ipv6.conf.eth0.accept_ra
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.accept_ra_from_local = 0
net.ipv6.conf.eth0.accept_ra_min_hop_limit = 1
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.accept_ra_rt_info_min_plen = 0
net.ipv6.conf.eth0.accept_ra_rtr_pref = 1

[trendy]

That’s interesting, seems that something is indeed messing up with your system.

[Zelaf]

On-top of that tailscale refuses to boot with the error

$ sudo tailscale up
failed to connect to local tailscaled (which appears to be running as tailscaled, pid 600513). Got error: Failed to connect to local Tailscale daemon for /localapi/v0/status; not running? Error: dial unix /var/packages/Tailscale/var/tailscaled.sock: connect: no such file or directory

I’ve tried restarting the service with no luck, gonna change the tailscale options and see what outcomes I can get, so far restarting the tailscale service doesn’t work.

I’m not good enough with sysctl to troubleshoot from here. I’ll see what I can search up but any pointers would be great.

[Zelaf]

Alright so Tailscale itself runs when I stop the systemctl service and then works when running manually. The output of systemctl status tailscaled

$ sudo systemctl status tailscaled
○ tailscaled.service - Tailscale node agent
     Loaded: loaded (/lib/systemd/system/tailscaled.service; enabled; preset: enabled)
     Active: inactive (dead) since Mon 2023-09-18 11:38:02 CEST; 4min 2s ago
   Duration: 15.516s
       Docs: https://tailscale.com/kb/
    Process: 758205 ExecStartPre=/usr/sbin/tailscaled --cleanup (code=exited, status=0/SUCCESS)
    Process: 758233 ExecStart=/usr/sbin/tailscaled --state=/var/lib/tailscale/tailscaled.state --socket=/run/tailscale/tailscaled.sock --port=${PORT} $FLAGS (code=exited, status=0/SUCCESS)
    Process: 758275 ExecStopPost=/usr/sbin/tailscaled --cleanup (code=exited, status=0/SUCCESS)
   Main PID: 758233 (code=exited, status=0/SUCCESS)
     Status: "Connected; accountInfo; TailnetIPs"
        CPU: 2.073s

The logs aren’t too helpful either on why it’s glitching out.