[SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

Corrupted · 2024-10-03 03:00:02

Hi all,

I recently switched my network stack following a long standing issue I was having with networkd intermittently dropping my network connection and ipv6 not getting assigned on service restart. I'm currently using iwd to handle WiFi connections and dhcpcd to assign ipv4 and temp ipv6 addresses.

This fixed the issue I was having with the connection dropping and IPv6 addresses not getting assigned on service restart. Right now the problem I'm having is that if the system is rebooted an IPv4 and temp IPv6 address isn't assigned to the wlan0 interface. I can work around this by restarting dhcpcd after logging in but, ideally, I wouldn't have to do this.

I'm not sure how to debug this. I figured that dhcpcd was trying to assign an address to wlan0 before iwd had a chance to setup the interface and establish a WiFi connection so I tried adding 'After iwd.service' to the dhcpcd service file but I'm still running into this issue.

If anyone has any debugging tips or ideas as to what might be causing this, I'd appreciate the help.

Last edited by Corrupted (2024-10-05 21:07:58)

-thc · 2024-10-03 06:48:53

Since iwd can do DHCP/IPv6 itself - why not giving it a try? https://wiki.archlinux.org/title/Iwd#En … figuration

seth · 2024-10-03 07:00:05

Next to pure iwd, please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

and

ip a

The default dhcpcd service/daemon/process just waits for anything to show up and get a carrier and you can also leverage https://wiki.archlinux.org/title/Dhcpcd#Hooks to have it automatically setup a specific wireless connection.

Corrupted · 2024-10-03 09:31:31

-thc wrote:

Since iwd can do DHCP/IPv6 itself - why not giving it a try? https://wiki.archlinux.org/title/Iwd#En … figuration

Thanks for the response. I was aware that iwd could do IPv6/DHCP but it wasn't immediately obvious to me, looking through the man page for iwd.config, if I could get it to do the equivalent of dhcpcd's slaac private temporary option. I'd like to continue using privacy extensions if at all possible. When I tried iwd it looked like it was just appending the hardware address to the end of the ipv6 address and I wasn't able to get a temporary IPv6 address out of iwd. Is there something in the kernel I would need to enable to get this working or is that just how iwd is?

Seth, the output of chain of commands you asked me to run is:

clamav-freshclam.service                 | multi-user.target.wants
dbus-org.freedesktop.home1.service       | system
dbus-org.freedesktop.timesync1.service   | system
dhcpcd.service                           | multi-user.target.wants
display-manager.service                  | system
dnsmasq.service                          | multi-user.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
iwd.service                              | multi-user.target.wants
libvirtd-ro.socket                       | sockets.target.wants
libvirtd.service                         | multi-user.target.wants
libvirtd.socket                          | sockets.target.wants
lm_sensors.service                       | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
performance-mode.service                 | multi-user.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
stubby.service                           | multi-user.target.wants
systemd-homed-activate.service           | systemd-homed.service.wants
systemd-homed.service                    | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
systemd-userdbd.socket                   | sockets.target.wants
virtlockd.socket                         | sockets.target.wants
virtlogd.socket                          | sockets.target.wants
wireplumber.service                      | pipewire.service.wants
xdg-user-dirs-update.service             | default.target.wants

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 noprefixroute
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr xx:xx:xx:xx:xx:xx
    inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever
3: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6

I was a bit hasty in stating everything was working I think. To get temp addresses functioning I had set net.ipv6.conf.*.temp_addr=2 which seemed to work with dhcpcd. Left for a few hours and when I came back a few new ipv6 addresses had been generated and the rest deprecated. All attempts to ping -6 at that point failed. I had to restart dhcpcd a few times to get ipv6 working again because the first couple resets of iwd and dhcpcd didn't give me an ipv6 period. Temp or otherwise. I'm a bit puzzled by this. It seems to work more consistently than networkd but I'm still running into a similar issue on top of wlan0 not receiving an address if I reboot my system.

-thc · 2024-10-03 09:40:50

SLAAC only provides the network side (routing prefix and subnet id, "first half") of the IPv6 address - the host part (interface identifier, "second half") is generated by the IPv6 stack itself.

With

net.ipv6.conf.*.temp_addr=2

you enable your host to generate temporary interface identifiers.

Try iwd alone with that kernel setting.

Last edited by -thc (2024-10-03 09:49:28)

seth · 2024-10-03 12:27:43

Do you also intend to use eno1?
If not, try iwd alone.

If yes, and because of the SLAAC situation, did you alter the default dhcpcd.conf?
I don't think the problem is that dhcpcd tries to obtain a lease before you've a carrier, we'll probably have to look at the journal to see where it's actually failing.

Sidebar: Is there a specific reason you've dnsmasq *and* stubby enabled?

Corrupted · 2024-10-03 20:02:07

seth wrote:

Do you also intend to use eno1?
If not, try iwd alone.
If yes, and because of the SLAAC situation, did you alter the default dhcpcd.conf?
I don't think the problem is that dhcpcd tries to obtain a lease before you've a carrier, we'll probably have to look at the journal to see where it's actually failing.
Sidebar: Is there a specific reason you've dnsmasq *and* stubby enabled?

No, eno1 isn't hooked up to anything. I'm just using wlan0. I've taken the suggestion to use iwd alone. The config I have for it:

[General]
EnableNetworkConfiguration=true
RoamThreshold=1
RoamThreshold5G=1
AddressRandomization=network
AddressRandomizationRange=full

[Network]
EnableIPv6=true

I've set net.ipv6.conf.all.addr_gen_mode=3 and net.ipv6.conf.all.use_tempaddr=2 in a sysctl.d file ( rebooted afterwards ).

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 noprefixroute
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr
    inet 192.168.1.26/24 scope global dynamic noprefixroute wlan0
       valid_lft 57407sec preferred_lft 57407sec
    inet6 2600:6c52:6200:1132:xxxx:xxxx:xxxx:xxxx/128 scope global dynamic noprefixroute
       valid_lft 545679sec preferred_lft 545679sec
    inet6 fe80::7fb8:25ef:64fb:92f/64 scope link stable-privacy proto kernel_ll
       valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6

So it does work. I consistently get an IPv4 and 6 address but it doesn't appear to use the privacy extension settings. It is randomizing the link local address but that just appears to be a result of the AddressRandomization option I set in general settings and not the sysctl modifications I made. The public facing IP address is still appending the actual hardware address and I'm not getting a temp address. I was trying to avoid this if at all possible which is why I had opted to use dhcpcd. While a bit flaky it was creating temp addresses in addition to not putting my hwaddr into the public facing address.

I didn't change much in the dhcpcd settings. I made three changes. One was to add temporary to the default slaac settings and the other two were enabling hardware address randomization and anonymous profile.

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
#hostname

# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid

# Persist interface configuration when dhcpcd exits.
# persistent

# vendorclassid is set to blank to avoid sending the default of
# dhcpcd-<version>:<os>:<machine>:<platform>
vendorclassid

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search

option classless_static_routes

# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Request a hostname from the network
option host_name

# Most distributions have NTP support.
option ntp_servers

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private temporary
# Do not attempt to obtain an IPv4LL address if we failed to get one via DHCP. See RFC 3927.
noipv4ll

randomise_hwaddr

anonymous

In regards to dnsmasq and stubby - I initially was just using dnsmasq as a replacement for resolved. I wanted to try getting DoT working so I added stubby and am am currently having dnsmasq pass requests off so stubby can encrypt them and send them off to mullvad or quad9. I imagine doing this prevents dnsmasq from being able to cache properly. If it does I'll likely just roll back my stubby changes and use dnsmasq exclusively. I don't really need DoT, I can just set up a vpn connection. Just wanted to see if I could get it working.

Last edited by Corrupted (2024-10-05 20:42:45)

Corrupted · 2024-10-04 06:10:26

Alright, so I had wireshark listen in on the wlan0 interface and filtered for DHCPv6, DHCP, ICMP and ICMPv6 packets and restarted iwd a few times.

seth is correct in that dhcpcd is waiting for the carrier to be acquired before before assigning an address. However there seems to be instances where DHCPv6 information packets are failing to send.

sudo journalctl -xeu dhcpcd

Oct 04 01:58:27 dhcpcd[16408]: wlan0: carrier acquired
Oct 04 01:58:27 dhcpcd[16408]: wlan0: IAID 25:ca:a3:72
Oct 04 01:58:27 dhcpcd[16408]: wlan0: adding address fe80::9c6b:998:be01:e88c
Oct 04 01:58:29 dhcpcd[16408]: wlan0: rebinding lease of 192.168.1.26
Oct 04 01:58:29 dhcpcd[16408]: wlan0: probing address 192.168.1.26/24
Oct 04 01:58:29 dhcpcd[16408]: wlan0: soliciting an IPv6 router
Oct 04 01:58:29 dhcpcd[16408]: wlan0: Router Advertisement from fe80::c5d:c8e6:ffe:f86a
Oct 04 01:58:29 dhcpcd[16408]: wlan0: adding route to fd93:ebff:3e78::/64 via fe80::c5d:c8e6:ffe:f86a
Oct 04 01:58:34 dhcpcd[16408]: wlan0: leased 192.168.1.26 for 86400 seconds
Oct 04 01:58:34 dhcpcd[16408]: wlan0: adding route to 192.168.1.0/24
Oct 04 01:58:34 dhcpcd[16408]: wlan0: adding default route via 192.168.1.1

2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ee:18:25:ca:a3:72 brd ff:ff:ff:ff:ff:ff permaddr
    inet 192.168.1.26/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 86185sec preferred_lft 75385sec
    inet6 fe80::9c6b:998:be01:e88c/64 scope link
       valid_lft forever preferred_lft forever

The above is a fail state when restarting iwd. In this case a DHCPv6 information request was never sent, or at least not picked up by wireshark. An initial DHCP request was made and my ipv4 was successfully set. I tested this a few times and in one instance a DHCPv6 information request was sent but I never received an AWK from the router.

Oct 04 02:40:33 dhcpcd[1096]: no interfaces have a carrier
Oct 04 02:40:33 dhcpcd[1096]: wlan0: waiting for carrier
Oct 04 02:40:34 dhcpcd[1096]: wlan0: carrier acquired
Oct 04 02:40:34 dhcpcd[1096]: wlan0: connected to Access Point: MyAccessPoint
Oct 04 02:40:34 dhcpcd[1096]: wlan0: IAID 19:b5:8c:0b
Oct 04 02:40:34 dhcpcd[1096]: wlan0: adding address fe80::f01e:de43:e33c:2653
Oct 04 02:40:35 dhcpcd[1096]: wlan0: rebinding lease of 192.168.1.26
Oct 04 02:40:36 dhcpcd[1096]: wlan0: soliciting an IPv6 router
Oct 04 02:40:37 dhcpcd[1096]: wlan0: Router Advertisement from fe80::3698:b5ff:fe48:48
Oct 04 02:40:37 dhcpcd[1096]: wlan0: adding address 2600:6c52:6200:1132:599c:79fd:32a6:72c/64
Oct 04 02:40:37 dhcpcd[1096]: wlan0: adding route to 2600:6c52:6200:1132::/64 via fe80::3698:b5ff:fe48:48
Oct 04 02:40:37 dhcpcd[1096]: wlan0: requesting DHCPv6 information
Oct 04 02:40:37 dhcpcd[1096]: wlan0: adding default route via fe80::3698:b5ff:fe48:48
Oct 04 02:40:40 dhcpcd[1096]: wlan0: DHCP lease expired
Oct 04 02:40:40 dhcpcd[1096]: wlan0: DHCP lease expired
Oct 04 02:40:40 dhcpcd[1096]: wlan0: soliciting a DHCP lease
Oct 04 02:40:45 dhcpcd[1096]: wlan0: REPLY6 received from fe80::3698:b5ff:fe48:48
Oct 04 02:40:45 dhcpcd[1096]: wlan0: refresh in 86400 seconds
Oct 04 02:40:46 dhcpcd[1096]: wlan0: Router Advertisement from fe80::c5d:c8e6:ffe:f86a
Oct 04 02:40:46 dhcpcd[1096]: wlan0: adding route to fd93:ebff:3e78::/64 via fe80::c5d:c8e6:ffe:f86a

The above is the journalctl log captured on a reboot. In this case it looks like it attempts to reuse the IP I had before rebooting. The lease is apparently expired so it requests a new one, after which nothing happens. I get an IPv6 address but an IPv4 is never assigned. I was unable to capture this with wireshark so I'm not sure if the request for a new DHCP lease ever made it off my system or if it was ignored by the router. When I did start capturing I just got a ton of arp messages "who is 192.168.1.26? Tell 192.168.1.1". I checked dmesg and saw the that the rtw_8822be driver was spamming "failed to leave lps state" After looking around a bit in the forums here and on github it appears the lps spam is caused by power save and issues with power save can sometimes cause connection issues. I set a udev rule to disable it.

It's too early to say that this fixed anything but as of typing this message I've reset dhcpcd and iwd independently and in tandem a few dozen times and I haven't had the ipv4 or ipv6 addresses fail to assign yet. The double lease expire and failure to obtain an ipv4 on boot continues to be an issue.

Last edited by Corrupted (2024-10-05 20:42:17)

seth · 2024-10-04 21:53:23

Did you set AlwaysRandomizeAddress ?
https://man.archlinux.org/man/iwd.netwo … l_Settings

Otherwise you'll recreate the same address
https://man.archlinux.org/man/extra/iwd … n#SETTINGS

The MAC is generated based on the SSID and permanent address of the adapter. This allows the same MAC to be generated each time connecting to a given SSID while still hiding the permanent address.

Did you "EnableNetworkConfiguration=false" for your dhcpcd investigation?

Corrupted · 2024-10-04 23:59:51

seth wrote:

Did you set AlwaysRandomizeAddress ?
https://man.archlinux.org/man/iwd.netwo … l_Settings
Otherwise you'll recreate the same address
https://man.archlinux.org/man/extra/iwd … n#SETTINGS
The MAC is generated based on the SSID and permanent address of the adapter. This allows the same MAC to be generated each time connecting to a given SSID while still hiding the permanent address.
Did you "EnableNetworkConfiguration=false" for your dhcpcd investigation?

I didn't set AlwaysRandomizeAddress. I wasn't aware this was an option as it wasn't listed in the iwd.config man pages on my system. I'll give that a go and post the results here.

I did disable EnableNetworkConfiguration for the dhcpcd investigation. The main.conf file had been set to:

[General]
EnableNetworkConfiguration=false

For the purpose of debugging this issue I've written a nushell function that overwrites the iwd main.conf file to the above before restarting iwd and starting dhcpcd. If I switch back to iwd the config I had posted in one of the previous comments is copied from a temp directory to /etc/iwd/main.conf and dhcpcd is stopped before iwd is restarted. I'm trying as best I can to minimize user errors by automating some of this.

I'm still debugging this. I have an Orbi mesh router. It doesn't have a firewall I can configure but it is running bitdefender armor. I'm not sure what this is doing outside of blacklisting potentially malicious URLS so I disabled it to make sure it wasn't doing something stupid like filtering packets sent from my system. This hasn't had an affect and I've since re-enabled it.

I've also tweaked some of the dhcpcd settings. I've blocked it from writing to resolv.conf as I do not want my ISP ( or router configured ) nameservers to be used. All requests should be passed off to 127.0.0.1 or ::1 so dnsmasq can handle them. I also removed anonymous and randomise_hwaddr just to see if this made a difference. I did notice an increase in IPv4 assignment failures with those settings turned on, specifically when resetting iwd, but turning those off didn't effect the failure case associated with rebooting my system.

If it would help at all I can dropbox the wireshark pcap files and link them here. I'll try your suggestion and am going to continue poking at my system and router settings to see if I can work out what's broken.

Last edited by Corrupted (2024-10-05 00:24:59)

seth · 2024-10-05 12:46:13

For clarification, does your edit imply "AlwaysRandomizeAddress" doesn't work as desired either?

Corrupted · 2024-10-05 20:37:51

seth wrote:

For clarification, does your edit imply "AlwaysRandomizeAddress" doesn't work as desired either?

No, I was just fixing some of the grammar on the post. I didn't have a chance to try it yesterday. I didn't see that option because I was looking in the wrong place. I didn't realize the psk files could or should have options tweaked on them. I added AlwaysRandomizeAddress and it does in fact work. This is a lot closer to what I am trying to achieve.

ip addr

    inet6 2600:6c52:6200:1132:f43d:f8ff:feb7:1752/128 scope global tentative dynamic noprefixroute
       valid_lft 369206sec preferred_lft 369206sec
    inet6 fe80::f43d:f8ff:feb7:1752/64 scope link proto kernel_ll

sudo systemctl restart iwd
...
ip addr

    inet6 2600:6c52:6200:1132:e057:60ff:fee0:11c8/128 scope global dynamic noprefixroute
       valid_lft 369160sec preferred_lft 369160sec
    inet6 fe80::e057:60ff:fee0:11c8/64 scope link proto kernel_ll

The address is randomized now. It's working as I would expect it to. What I was hoping to get working was temporary addresses:

sudo nvim /etc/iwd/main.conf // disable network configuration
...
sudo systemctl restart iwd
sudo systemctl start dhcpcd
ip addr

    inet6 2600:6c52:6200:1132:229:5a85:aa8a:9fc8/64 scope global temporary dynamic
       valid_lft 369046sec preferred_lft 86377sec
    inet6 2600:6c52:6200:1132:441:ee51:59c1:c39a/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 369046sec preferred_lft 369046sec
    inet6 fe80::a4cb:8dff:fee5:b7d2/64 scope link proto kernel_ll

inet6 2600:6c52:6200:1132:229:5a85:aa8a:9fc8/64 scope global temporary dynamic - Same randomization but the address will, after some time, deprecate and a new one will be assigned. I can get this working with dhcpcd but not with iwd. While switching to iwd wasn't exactly the solution I was hoping for and it looks like I wont be getting my temp addresses - the address randomization is working as expected and close enough to what I was trying to achieve. iwd doesn't seem to have the same issues dhcpcd and networkd have with ipv6, ipv4 or both just randomly failing to assign so I think I'll stick with it until I work out what's busted on my system or an update fixes the issue ( assuming this is a bug in the kernel or with networkd/dhcpcd and not just some funkiness with my hardware and/or router ).

Thanks!

Last edited by Corrupted (2024-10-05 21:02:35)

cryptearth · 2024-10-05 21:46:54

Corrupted wrote:

privacy

I haven't read all of it so I may missed it - but what excatly is your goal?
From your reply what happens is what I expected: You always get an IP in the range of 2600:6c52:6200:1132::/64 - looking that up on https://ipinfo.io/2600:6c52:6200:1132:: returns AS20115 - Charter Communications, an ISP AS with the range 2600:6c52::/32. So anyone with a bit of knowledge how IPv6 works knows that 2600:6c52:6200:1132::/64 is some residential customer connection and that all requests comming from it either multiple devices or even the same (can be inferred from additional meta data).
Don't get me wrong - yes, I do hate all that tracking myself and can't laugh about that companies like google make money selling my data - but is all that effort worth it in the just to not see a random ad rather than a customized one which gets hidden by some ad block anyway?
If I would be a data broker for me it would already be enough to know "ah, it's family Smith from Gilroy, California again" - and maybe I could even identify the device the request originates from and from that maybe even the user - the random 64-bit host identifier would be ignore anyway.

fun fact: when trying to access charter.com it redirects me to spectrum.com which just gets me a big "ACCESS DENIED" because it detects I'm not from the state of california but from germany and hence completely blocks me of thier site - or is it something only customers of "what ever that isp is called" can even access? that's some crap marketing on thier end

progandy · 2024-10-05 22:44:13

cryptearth wrote:

fun fact: when trying to access charter.com it redirects me to spectrum.com which just gets me a big "ACCESS DENIED" because it detects I'm not from the state of california but from germany and hence completely blocks me of thier site - or is it something only customers of "what ever that isp is called" can even access? that's some crap marketing on thier end

I'd guess they don't want to deal with GDPR and blocked the EU.

Corrupted · 2024-10-06 00:21:59

cryptearth wrote:

I haven't read all of it so I may missed it - but what excatly is your goal?
From your reply what happens is what I expected: You always get an IP in the range of 2600:6c52:6200:1132::/64 - looking that up on https://ipinfo.io/2600:6c52:6200:1132:: returns AS20115 - Charter Communications, an ISP AS with the range 2600:6c52::/32. So anyone with a bit of knowledge how IPv6 works knows that 2600:6c52:6200:1132::/64 is some residential customer connection and that all requests comming from it either multiple devices or even the same (can be inferred from additional meta data).
Don't get me wrong - yes, I do hate all that tracking myself and can't laugh about that companies like google make money selling my data - but is all that effort worth it in the just to not see a random ad rather than a customized one which gets hidden by some ad block anyway?
If I would be a data broker for me it would already be enough to know "ah, it's family Smith from Gilroy, California again" - and maybe I could even identify the device the request originates from and from that maybe even the user - the random 64-bit host identifier would be ignore anyway.
fun fact: when trying to access charter.com it redirects me to spectrum.com which just gets me a big "ACCESS DENIED" because it detects I'm not from the state of california but from germany and hence completely blocks me of thier site - or is it something only customers of "what ever that isp is called" can even access? that's some crap marketing on thier end

Well the goal initially was just to figure out why I wasn't assigned an address on reboot and fix it. The suggestion was to use iwd to configure the network/interface. I wanted to continue using ipv6 privacy extensions so I wasn't exposing my MAC/hardware address to every site ( that supports ipv6 which as it turns out, isn't many. At least in the US ) I visit. I'm aware that this doesn't offer absolute privacy and that data collection companies will still be able to fingerprint and track me, but exposing my hardware address feels wrong and it doesn't take too much effort to configure your system to not do that. For the most part I run through a VPN so whether or not my address is randomized usually doesn't matter. There are some instances where a site or service will detect I'm running through a VPN and block the connection. It's these cases that I'd like privacy extensions to work.

Last edited by Corrupted (2024-10-06 06:12:22)

cryptearth · 2024-10-06 07:30:09

progandy wrote:

I'd guess they don't want to deal with GDPR and blocked the EU.

well - now as you say it - I myself have blocked several countries on my lists - but from me they don't get anything back - I just drop thier packets

@OP
ah, ok, so I do have missed the initial issue, my bad, sorry
as for not telling the internet about my hardware: well, as I do host several services like my own e-mail server it's easy to find pretty much anything about me with little effort - it's also because I have to provide certain information by german law
to get even further: the following may sound a bit like chinese propaganda - but if someone would offer a service for exclusive online play to lock out cheaters and hackers but would require registraion of hardware and personal information along with some special software to be run - I actually would consider to sign up just to get that sweet exclusive cheater-free heaven
why? because then at least it would be my active choice and consent instead of all this useless anti-cheat crap
have a look at rockstar which recently enabled BattlEye and locked out linux - the problem isn't BattlEye, it works great in Arma3 - the problem is Rockstar not enabling Proton access - yet they wrongly blame Valve with "the steamdeck isn't compatible" when it's actually them not enable support for BE on proton
and in the end it's a useless dick move because BattlEye is easy to get around and broken for years - so while Linux gets locked out for no reason cheaters and hackers keep cheating snd hacking - and all they won is the anger of linux users like me

-thc · 2024-10-06 11:27:13

Corrupted wrote:

Oct 04 01:58:29 dhcpcd[16408]: wlan0: Router Advertisement from fe80::c5d:c8e6:ffe:f86a

Oct 04 02:40:37 dhcpcd[1096]: wlan0: Router Advertisement from fe80::3698:b5ff:fe48:48:f86a

Did you notice during your tests that you receive RAs from two different IPv6 routers? This may be the reason behind your troubles.

Only the second one quoted here is a Netgear router.

Corrupted · 2024-10-06 17:28:55

-thc wrote:

Corrupted wrote:
Oct 04 01:58:29 dhcpcd[16408]: wlan0: Router Advertisement from fe80::c5d:c8e6:ffe:f86a
Oct 04 02:40:37 dhcpcd[1096]: wlan0: Router Advertisement from fe80::3698:b5ff:fe48:48:f86a
Did you notice during your tests that you receive RAs from two different IPv6 routers? This may be the reason behind your troubles.
Only the second one quoted here is a Netgear router.

No I didn't notice that. Not sure where that would be coming from. I only have the one router and the two satellites. There's a pihole on the network that hasn't been used in a long time, but I don't think it was setup to act as a DHCP server. I'll try taking that offline and see if I continue to receive multiple RA's.

Corrupted · 2024-10-06 19:50:18

The other RA was coming from an Apple Tv device. I'm not sure why it feels compelled to send out RA's. Apparently they have their own system for obtaining IPv6 addresses. It's rather annoying that this is getting picked up by other devices on the network. I unplugged it but it hasn't had an affect.

The issues seem to have something to do with hardware randomization. If I enable hardware randomization on iwd's side and disable it from dhcpcd then I get an IPv6 on reboot or iwd restart but not an ipv4. Wireshark shows that DHCP requests are being sent but they're not acknowledged by the router. If I disable randomization then everything works. I'm assigned an IPv4 and IPv6 address on reboot and service restart. If I enable randomization and anonymous on dhcpcd's side this, for some reason, interferes with iwd and the interface doesn't get brought up. If I restart iwd following a reboot, the interface is brought up successfully and I receive an IPv4 and IPv6 address as expected. If I just disable hardware randomization outright then ip assignment works on service restart and reboots of the system.

Something about hardware randomization isn't sitting right with my router and if it's enabled on dhcpcd's side it seems to interfere with iwd. I'm just going to disable it. This is a desktop PC running on my home network. It weighs 60 pounds and there's a zero percent chance I'm going to be dragging this out to a coffee shop or hotel where having hw randomization enabled might make more sense. I just need the global addresses to not expose my MAC and at the moment they aren't.

Last edited by Corrupted (2024-10-06 20:00:15)

Arch Linux

#1 2024-10-03 03:00:02

[SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#2 2024-10-03 06:48:53

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#3 2024-10-03 07:00:05

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#4 2024-10-03 09:31:31

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#5 2024-10-03 09:40:50

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#6 2024-10-03 12:27:43

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#7 2024-10-03 20:02:07

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#8 2024-10-04 06:10:26

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#9 2024-10-04 21:53:23

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#10 2024-10-04 23:59:51

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#11 2024-10-05 12:46:13

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#12 2024-10-05 20:37:51

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#13 2024-10-05 21:46:54

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#14 2024-10-05 22:44:13

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#15 2024-10-06 00:21:59

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#16 2024-10-06 07:30:09

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#17 2024-10-06 11:27:13

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#18 2024-10-06 17:28:55

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

#19 2024-10-06 19:50:18

Re: [SOLVED] Dhcpcd: wlan0 interface not assigned IPv4 or IPv6 on boot

Board footer