No IPv4 on WiFi, but does work on cellular

Ask Fedora
, , , ,
1

On my Fedora 35 laptop I’m suddenly not getting an IPv4 address on my WiFi interface anymore. I am, however, getting an IPv4 address on my cellular interface. Even if I specify an IPv4 address in GNOME’s network settings it’s not being applied to the interface. Any idea what’s happening?

The only thing that I changed recently is that I swapped the old Dell WiFi card in my laptop with an Intel AX210. I am completely up-to-date, running kernel Linux kanata 5.16.15-201.fc35.x86_64 #1 SMP PREEMPT Thu Mar 17 05:45:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ ip a s
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: wwp0s20u10i12: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1430 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 56:66:51:53:96:a1 brd ff:ff:ff:ff:ff:ff
    inet 83.161.168.xxx/26 brd 83.161.168.xxx scope global noprefixroute wwp0s20u10i12
       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 f8:ca:b8:22:b8:36 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
4: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 8c:b8:7e:f8:61:19 brd ff:ff:ff:ff:ff:ff
    inet6 2001:981:19d2:1:9366:1a22:e744:9534/64 scope global dynamic noprefixroute 
       valid_lft 6041sec preferred_lft 3313sec
    inet6 fe80::3e04:8795:45a4:fd34/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

NetworkManager is also only mentioning my cellular interface:

$ PAGER= systemctl status NetworkManager
● NetworkManager.service - Network Manager
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-03-19 22:08:39 CET; 15min ago
       Docs: man:NetworkManager(8)
   Main PID: 1257 (NetworkManager)
      Tasks: 3 (limit: 19003)
     Memory: 10.3M
        CPU: 948ms
     CGroup: /system.slice/NetworkManager.service
             └─1257 /usr/sbin/NetworkManager --no-daemon

Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3330] modem-broadband[cdc-wdm0]:   address 83.161.168.xxx/26
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3330] modem-broadband[cdc-wdm0]:   gateway 83.161.168.xxx
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3330] modem-broadband[cdc-wdm0]:   DNS 194.109.6.66
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3331] modem-broadband[cdc-wdm0]:   DNS 194.109.9.99
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3331] modem-broadband[cdc-wdm0]:   MTU 1430
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3376] device (cdc-wdm0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3417] device (cdc-wdm0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3419] device (cdc-wdm0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3424] policy: set 'XS4ALL Mobiel Internet' (wwp0s20u10i12) as default for IPv4 routing and DNS
Mar 19 22:21:46 kanata NetworkManager[1257]: <info>  [1647724906.3435] device (cdc-wdm0): Activation: successful, device activated.
2

Is IPv4 enabled for that connection?

nmcli connection show <YOUR_CONNECTION_NAME> | grep ipv4
3

Defintely looks like it, currently set to auto:

$ nmcli connection show "The den" | grep ipv4
ipv4.method:                            auto
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.required-timeout:                  -1 (default)
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-reject-servers:               --

And even when manually setting it in the GUI, nothing. That changes the following lines:

ipv4.method:                            manual
ipv4.addresses:                         192.168.178.250/24
ipv4.gateway:                           192.168.178.1

Even then it shows nothing:

$ ip a s wlp3s0
4: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 8c:b8:7e:f8:61:19 brd ff:ff:ff:ff:ff:ff
    inet6 2001:981:19d2:1:7b29:5b74:d844:8abe/64 scope global dynamic noprefixroute 
       valid_lft 7104sec preferred_lft 3534sec
    inet6 fe80::fd14:46ba:6889:db97/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4

To add weirdness, after a sleep/wake cycle I am getting my statically set IP address. Dynamic doesn’t work yet though.

5

Unless you really need it you could disable ipv6 in network settings so it will only connect with ipv4.

6

Disabling IPv6 didn’t work either. What I did (and I have no idea why it worked) is:

  • Run rm /var/lib/NetworkManager/*.lease as root
  • Retry (this didn’t fix the issue)
  • Turn off firewalld
  • Retry

Now it suddenly works again. Even with firewalld now running again it still seems to work. It’s really weird. Now it’s not just an endless stream of DHCP requests anymore. Instead, it’s the normal discover => offer => request => ack sequence.