Arch i3wm ip válido, problema de DHCP

1

relacionado mas resolvido pela solução alternativa: No Archlinux, ele tem um ip válido, mas nenhuma conexão pôde ser estabelecida

Então meu sistema de arquivamento ficou "offline" há algum tempo. Não me incomodei muito porque usei o windows vm que tinha internet via ponte de rede. O engraçado é que se eu abro o networkManager e excluo minha conexão, ele imediatamente é reiniciado e a Internet está disponível sob o arco até que o i3wm mostre o IP na barra de status (~ 3s). Agora estou tentando voltar ao normal pela terceira vez e preciso de ajuda.

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

r

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 <LOOPBACK,UP,LOWER_UP> 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 <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> 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 <BROADCAST,MULTICAST,UP,LOWER_UP> 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 <BROADCAST,MULTICAST,UP,LOWER_UP> 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

Eu realmente aprecio todas as ideias.

    
por Falk 23.07.2018 / 21:54

1 resposta

0

Alguma peculiaridade de sua configuração está interferindo no pacote resolconf , ou você estava manipulando / copiando em /etc/resolv.conf ou alguns de seus pacotes não levam em conta a instalação de resolv.conf . Conhecendo o arch linux, aposto na probabilidade tardia.

O caminho de menor resistência pode ser realmente melhor por um usuário inexperiente excluindo o pacote resolvconf em vez de tentar consertar o symlink resolv.conf e / ou descobrir qual pacote deve ser (re) configurado.

O

resolvconf também é conhecido por interferir também com VPNs, e eu geralmente prefiro desinstalar o pacote em meus servidores e desktops, mesmo sabendo como lidar com ele.

    
por 23.07.2018 / 22:19