Boot error message: wpa dependency failed for interface

That is weird:

aug 30 18:05:37 popa-20384 NetworkManager[874]: <info>  [1598799937.4050] device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "TP-Link_F09E"

Wifi is working, but here it is timed out:

aug 30 18:06:33 popa-20384 systemd[1]: Timed out waiting for device /sys/subsystem/net/devices/wlp9s0.
aug 30 18:06:33 popa-20384 systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
aug 30 18:06:33 popa-20384 systemd[1]: wpa_supplicant@wlp9s0.service: Job wpa_supplicant@wlp9s0.service/start failed with result 'dependency'.
aug 30 18:06:33 popa-20384 systemd[1]: sys-subsystem-net-devices-wlp9s0.device: Job sys-subsystem-net-devices-wlp9s0.device/start failed with result 'timeout'.
aug 30 18:06:33 popa-20384 systemd[1]: Reached target Network.
aug 30 18:06:33 popa-20384 systemd[1]: Reached target Network is Online.

The NetworkManager says:

aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.3597] settings: Loaded settings plugin: keyfile (internal)
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.6439] device (lo): carrier: link connected
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.6446] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.6462] manager: (enp8s0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.6474] device (enp8s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
aug 30 18:05:32 popa-20384 ModemManager[922]: <info>  ModemManager (version 1.14.2) starting in system bus...
aug 30 18:05:32 popa-20384 kernel: Generic FE-GE Realtek PHY r8169-800:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-800:00, irq=IGNORE)
aug 30 18:05:32 popa-20384 kernel: r8169 0000:08:00.0 enp8s0: Link is Down
aug 30 18:05:32 popa-20384 systemd-networkd[398]: enp8s0: Link UP
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.8582] device (wlan0): driver supports Access Point (AP) mode
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.8603] manager: (wlan0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/3)
aug 30 18:05:32 popa-20384 NetworkManager[874]: <info>  [1598799932.8624] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
aug 30 18:05:33 popa-20384 systemd-networkd[398]: wlan0: Link UP
aug 30 18:05:33 popa-20384 systemd-networkd[398]: wlan0: Link DOWN
aug 30 18:05:33 popa-20384 NetworkManager[874]: <info>  [1598799933.5394] device (wlan0): set-hw-addr: set MAC address to FE:92:D1:61:7A:0F (scanning)

Your wired connection gets renamed:

aug 30 18:05:15 popa-20384 kernel: r8169 0000:08:00.0 enp8s0: renamed from eth0

but not your wlan0 to wlp9s0.

I thing the network manager tries to start wlan0, this is this is the wrong name. It is wlp9s0. And there we have the interface-specific version Dependency error.

Could you post the output of:

ip a

Did you configure the WIFI somehow manually instead of using the network-manager? Is wlan0 set there or wlp9s0 as device?

What about the other errors?

~ >>> 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: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ba:08:70:4b:ed:e5 brd ff:ff:ff:ff:ff:ff permaddr f8:a9:63:35:b2:97
    inet 192.168.0.101/24 brd 192.168.0.255 scope global dynamic noprefixroute enp8s0
       valid_lft 7080sec preferred_lft 7080sec
    inet6 fe80::f842:81d6:11b2:9b64/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 38:b1:db:50:8b:65 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.104/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 7081sec preferred_lft 7081sec
    inet6 fe80::c532:edb7:adbc:8e61/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: proton0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.16.0.24/16 brd 10.16.255.255 scope global proton0
       valid_lft forever preferred_lft forever
    inet6 fe80::10df:a860:988:1ec9/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

These errors are not related to the wifi. Create a new topic if you want to fix them, but in general these are UEFI problems.

Can you switch the device wlan0 to wlp9s0 in the NetworkManager? If not there, write it.
I guess it is this application: nm-connection-editor

I already did.

Does it work? :smiley:

When the computer had booted there were no errors, only when I had closed the computer, before booting, but it was too fast for me to see.

I mean… is the Wifi Connection working?

No, it still doesn’t work. I can connect and it shows as connected but it doesn’t get me online. And if I disconnect the wired connection and reconnect it, I cannot go online.

Sorry myself i have no idea now. I buried out my laptop and started it with gnome.

eth0 gets renamed and wlan0 gets renamed
and the NetworkManager uses the new names.

eth0 (wired connection) gets renamed to enp8s0.
Your NetworkManager uses the name wlan0, but it should use the renamed wlp9s0.

I guess it has something to with protonvpn, not sure when your problems started.

On the clean installation there is not such a problem.

Maybe someone else with better knowledge could help you.

It really was a clean install, from USB.

vi /etc/udev/rules.d/70-persistent-net.rules
inserting this
> SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“7c:fe:90:cb:76:02”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth1”
>
>
>
> SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“7c:fe:90:cb:76:03”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth2”
then doing this:
cat /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE="eth1"

BOOTPROTO="static"

HWADDR="7c:fe:90:cb:76:02"

IPADDR=1.1.1.2

NETMASK=255.255.255.0

ONBOOT="yes"

then doing this

ifconfig

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 1.1.1.2 netmask 255.255.255.0 broadcast 1.1.1.255

inet6 fe80::7efe:90ff:fecb:7602 prefixlen 64 scopeid 0x20<link>

ether 7c:fe:90:cb:76:02 txqueuelen 1000 (Ethernet)

RX packets 0 bytes 0 (0.0 B)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 23 bytes 3208 (3.1 KiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

ether 7c:fe:90:cb:76:03 txqueuelen 1000 (Ethernet)

RX packets 0 bytes 0 (0.0 B)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 0 bytes 0 (0.0 B)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

is this a safe method? should I try it?

@moderators Do you have any idea what could be the solution here? I see a possible problem, but I don’t know how it can be solved. Thanks.

What other custom configurations have you created? Without knowing from what documentation you got them, so we have context, things might get misinterpreted.

From what i gathered is about a Lenovo Z50-75
Can’t tell is some kernel boot parameters will help or not.
See here:

Have a read here about that wifi model:


and even tho this is older, still has some valuable information there
https://bbs.archlinux.org/viewtopic.php?id=208472

It is great if you play with your system - learning the inner workings - keep going.

timeshift is a fantastic tool

:grey_exclamation: Make notes - so you can back trace your changes and revert if not working. Do not make many changes at once - small steps.

And when you end up like this you need to revert every change you made to your configuration and start fresh.

Please remove the files

  • /etc/udev/rules.d/70-persistent-net.rules
  • /etc/sysconfig/network-scripts/ifcfg-eth1
$ whois 1.1.1.2
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '1.1.1.0 - 1.1.1.255'

% Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse@apnic.net'

inetnum:        1.1.1.0 - 1.1.1.255
netname:        APNIC-LABS
descr:          APNIC and Cloudflare DNS Resolver project
descr:          Routed globally by AS13335/Cloudflare
descr:          Research prefix for APNIC Labs

....

You cannot assign a cloudflare IP to a local interface - this will break your network connection - as I assume your resolv.conf also looks for cloudflare dns.

  • Watchdog messages can be ignored.
  • In configuration files you need to use the correct interface names.

Manjaro uses systemd and systemd names interfaces from their system location (their connection point either system board slot or USB hub and port number. This approach creates a predictable but can be annoying to handle.

You can get interface names using various commands e.g.

ip a | grep ' state UP' | cut -d' ' -f2 | cut -d':' -f1

If you really want to change your interface names to the old names - just create the following symlink and restart

ln -sf /dev/null /etc/udev/rules.d/80-net-setup-link.rules

I recently played with changing the mentioned systemd behaviour and found that moving around the interface I could make scripts which depended on a specific interface fail (No - I won’t go into details - but it is possible).

rtl8723be

enp8s0
wlan0

Having both enp8s0 and wlan0 name types is confusing - go with one or another.

Don’t implement guides found on the internet unless you really understand what you are doing - and be prepared to roll back any change you make.

I’ve reinstalled manjaro and it only works with the wired connection.

Then you need to check the search result from the archived forum mentioned in above comment on rtl8723be - as it is known to create issues.

Ok, right now I am not connected to protonvpn but the internet works fine on wifi. I have no idea what is happening…

But where did protonvpn come from?

Why haven’t you mentioned protonvpn before? Has the this been a factor the whole time?

You are getting somewhere :+1:

Now you know that your connection issue is related to the changes protonvpn makes to your dns and routing.

I known of the proton vpn gui - but the last time I checked you could make bad decisions in the gui.

EDIT: use the command

sudo protonvpn configure

If you have changed the defaults for option 4-5-6 please purge your config to the defaults.

ProtonVPN is a paid service with their own priority support. Please contact them if your issues continue.

If you have enabled the killswitch be aware that this will produce results like you have described earlier - you interface shows as connected but you can access nothing.