Arch i3wm действительный ip, проблема с DHCP

связанные, но решаемые обходным путем: в Archlinux он имеет действительный IP-адрес, но соединение не может быть установлено

Так что моя система арок отключилась некоторое время назад. Я не особо беспокоился, потому что я использовал Windows VM, у которой был Интернет через сетевые мосты. Самое смешное, что если я открываю networkManager и удаляю свое соединение, оно немедленно сбрасывается, и интернет доступен в режиме arch, пока i3wm не покажет IP в строке состояния (~ 3 с). Теперь я пытаюсь вернуть его в нормальное состояние в третий раз и мне нужна помощь.

uname -a Linux iamgroot 4.16.12-1-ARCH #1 SMP PREEMPT Fri May 25:30:31 UTC 2018 x86_64 GNU/Linux

р

cat /etc/resolv.conf \# Generated by resolvconf #escaped for stackexchange codeformatting domain fritz.box nameserver 192.168.178.1

ip route default via 192.168.178.1 dev en3ps0 proto dhcp src 192.168.178.37 metric 202 default via 192.168.178.1 dev bridge_qemu_0 proto dhcp src 192.168.178.37 metric 203 192.168.178.0/24 dev en3ps0 proto dhcp scope link src 192.168.178.37 metric 202 192.168.178.0/24 dev bridge_qemu_0 proto dhcp scope link src 192.168.178.37 metric 203

ping stackexchange.com ping: stackexchange.com: Temporary failure in name resolution

ip addr 1: lo mtu 65536 qdisc nonqueue state UNKOWN 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: en3ps0 mtu 1500 qdisc fq_codel master bridge_qemu_0 state UP group default qlen 1000 link/ether d4:3d:7e:bd:ec:ce brd ff:ff:ff:ff:ff:ff inet 192.168.278.37/24 brd 192.168.178.255 scope global noprefixroute en3ps0 valid_lft forever preferred_lft forever 3: bridge_qemu_0 mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether d4:3d:7e:bd:ec:ce brd ff:ff:ff:ff:ff:ff inet 192.168.278.37/24 brd 192.168.178.255 scope global noprefixroute bridge_qemu_0 inet6 fe80::2b75:33d9:ac58:3c55/64 scope link valid_lft forever preferred_lft forever 4: tap0 mtu 1500 qdisc fq_codel master bridge_qemu_0 state UNKNOWN group default qlen 1000 link/ether fe:0d:6e:2d:8f:aa brd ff:ff:ff:ff:ff:ff inet6 fe80::8a0b:fb95:5201:6d6a/64 scope link valid_lft forever preferred_lft forever inet6 fe80::fc0d:6eff:fe2d:8faa/64 scope link valid_lft forever preferred_lft forever

Я был бы очень признателен за все идеи.

Либо какая-то особенность вашей конфигурации вмешивается в пакет resolconf , либо вы манипулировали / копировали через /etc/resolv.conf либо некоторые из ваших пакетов не учитывали наличие resolv.conf . Зная Arch Linux, я делаю ставку на позднюю вероятность.

Путь меньшего сопротивления может быть действительно лучше для неопытного пользователя, resolvconf пакет resolvconf вместо того, чтобы пытаться исправить символическую ссылку resolv.conf и / или выяснить, какой пакет следует (пере) настроить.

resolvconf также мешает работе VPN, и я обычно предпочитаю удалять пакет с моих серверов и рабочих столов, даже не зная, как с этим обращаться.