Reinstalei o Ubuntu e a conexão não funciona mais

selvaking · 30 de Julho de 2016, 20:14

Só pra desencargo de consciencia.

Coloca a saida do comando abaixo:

for a in /etc/NetworkManager/system-connections/*; do echo +++++ "${a}" +++++ && sudo cat "${a}"; done;

mateus_hst · 30 de Julho de 2016, 20:45

Citação de: selvaking online 30 de Julho de 2016, 20:14
Só pra desencargo de consciencia.

Coloca a saida do comando abaixo:

Código Selecionar Expandir
for a in /etc/NetworkManager/system-connections/*; do echo +++++ "${a}" +++++ && sudo cat "${a}"; done;

Olá selvaking,
feito o comando deu isso aqui:

mateus@mateus-hst:~$ for a in /etc/NetworkManager/system-connections/*; do echo +++++ "${a}" +++++ && sudo cat "${a}"; done;
+++++ /etc/NetworkManager/system-connections/Conexão cabeada 1 +++++
[sudo] senha para mateus:
[connection]
id=Conexão cabeada 1
uuid=1f578f51-3d53-4d12-8ab0-83382570c7f9
type=ethernet
autoconnect-priority=-999
interface-name=enp5s0
permissions=
secondaries=
timestamp=1469894357

[ethernet]
duplex=full
mac-address=74:D4:35:E1:53:EE
mac-address-blacklist=

[ipv4]
address1=192.168.1.100/24,192.168.1.1
dns=8.8.8.8;
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto
+++++ /etc/NetworkManager/system-connections/Conexão Ethernet 1 +++++
[connection]
id=Conexão Ethernet 1
uuid=e67d7ba5-c762-4c6e-983d-ad5a12b97097
type=ethernet
permissions=
secondaries=

[ethernet]
duplex=full
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto

selvaking · 30 de Julho de 2016, 21:05

Remova estes três arquivos e reinicie a máquina.

Código Selecionar

sudo rm /etc/NetworkManager/system-connections/Conexão\ cabeada\ 1 /etc/NetworkManager/system-connections/Conexão\ Ethernet\ 1
/etc/udev/rules.d/70-persistent-net.rules

mateus_hst · 30 de Julho de 2016, 22:45

Citação de: selvaking online 30 de Julho de 2016, 21:05
Remova estes três arquivos e reinicie a máquina.

Código Selecionar Expandir
sudo rm /etc/NetworkManager/system-connections/Conexão\ cabeada\ 1 /etc/NetworkManager/system-connections/Conexão\ Ethernet\ 1 /etc/udev/rules.d/70-persistent-net.rules

rm: não foi possível remover '/etc/NetworkManager/system-connections/Conexão cabeada 1': Arquivo ou diretório não encontrado
rm: não foi possível remover '/etc/NetworkManager/system-connections/Conexão Ethernet 1': Arquivo ou diretório não encontrado

:/

zekkerj · 30 de Julho de 2016, 23:31

Essa sequência de "link up" não é normal. $:-\$
Mas seria preciso entender o motivo disso.

mateus_hst · 31 de Julho de 2016, 00:50

Gente, dei jeito.
Estou escrevendo do meu desktop. Aquele mesmo que a ethernet não funcionava nem a pau.
O que eu fiz?
Instalei o Ubuntu 16.04.1 - dessa vez o 32 bits.
Durante a instalação já apareceu a opção de atualizar os pacotes online.
Agora está tudo certo.
Gostaria de saber o porquê funcionou.
Alguém tem alguma teoria a respeito?

Obrigado a todos que me deram uma força.
Espero poder contribuir e divulgar o GNU/Linux pra todos,

druidaobelix · 31 de Julho de 2016, 04:48

Citação de: mateus_hst online 31 de Julho de 2016, 00:50
Estou escrevendo do meu desktop. Aquele mesmo que a ethernet não funcionava nem a pau.
O que eu fiz?
Instalei o Ubuntu 16.04.1 - dessa vez o 32 bits.
Durante a instalação já apareceu a opção de atualizar os pacotes online.
Agora está tudo certo.
Gostaria de saber o porquê funcionou.
Alguém tem alguma teoria a respeito?

Isso apenas não faz o menor sentido, basta que se faça o retrospecto de tudo quanto se conversou neste tópico e das providência que você disse que fez, inclusive fazendo instalações "limpas" sucessivas das versões 14.04 e da 16.04.

A única teoria que tenho é que você alterou mais alguma coisa no seu roteador e que não ficamos sabendo mais exatamente o que seja, porque na verdade só você mesmo sabe o que está acontecendo aí como um todo.

Como já havia comentado antes, o intervalo de atribuição de ip era o 20 e sobre o qual comentei lá no post #23, entretanto, refazendo comandos já agora no post #42 a faixa de ip foi alterada para 100. Só há um modo disso acontecer, alguém alterou alguma configuração no seu roteador e do lado de cá não fomos comunicados e não ficamos sabendo disso, nada nos foi dito sobre isso.

Na verdade não aprendemos nada sobre o problema, podemos encerrar o tópico porque afinal o problema foi resolvido, mas se você quiser usar a situação para tentar aprender mais alguma coisa, refaça os comandos já feitos antes e podemos fazer a comparação.

Essa cesta de comandos, querendo, pode ajudar a melhor entender o cenário:

Código Selecionar

cat /etc/lsb-release

Código Selecionar

sudo lshw -c network

Código Selecionar

ifconfig -a

Código Selecionar

nmcli d show

Código Selecionar

ping -c 4 192.168.1.1

Código Selecionar

ping -c 4 8.8.8.8

Código Selecionar

ping -c 4 www.google.com

Além disso, suba o sistema usando um live-iso de 64-bit e veja se a conexão funciona ou não, é o tira-teima.

mateus_hst · 31 de Julho de 2016, 09:46

Citação de: druidaobelix online 31 de Julho de 2016, 04:48
Citação de: mateus_hst online 31 de Julho de 2016, 00:50
Estou escrevendo do meu desktop. Aquele mesmo que a ethernet não funcionava nem a pau.
O que eu fiz?
Instalei o Ubuntu 16.04.1 - dessa vez o 32 bits.
Durante a instalação já apareceu a opção de atualizar os pacotes online.
Agora está tudo certo.
Gostaria de saber o porquê funcionou.
Alguém tem alguma teoria a respeito?

Isso apenas não faz o menor sentido, basta que se faça o retrospecto de tudo quanto se conversou neste tópico e das providência que você disse que fez, inclusive fazendo instalações "limpas" sucessivas das versões 14.04 e da 16.04.

A única teoria que tenho é que você alterou mais alguma coisa no seu roteador e que não ficamos sabendo mais exatamente o que seja, porque na verdade só você mesmo sabe o que está acontecendo aí como um todo.

Como já havia comentado antes, o intervalo de atribuição de ip era o 20 e sobre o qual comentei lá no post #23, entretanto, refazendo comandos já agora no post #42 a faixa de ip foi alterada para 100. Só há um modo disso acontecer, alguém alterou alguma configuração no seu roteador e do lado de cá não fomos comunicados e não ficamos sabendo disso, nada nos foi dito sobre isso.

Na verdade não aprendemos nada sobre o problema, podemos encerrar o tópico porque afinal o problema foi resolvido, mas se você quiser usar a situação para tentar aprender mais alguma coisa, refaça os comandos já feitos antes e podemos fazer a comparação.

Essa cesta de comandos, querendo, pode ajudar a melhor entender o cenário:

Código Selecionar Expandir
cat /etc/lsb-release

Código Selecionar Expandir
sudo lshw -c network

Código Selecionar Expandir
ifconfig -a

Código Selecionar Expandir
nmcli d show

Código Selecionar Expandir
ping -c 4 192.168.1.1

Código Selecionar Expandir
ping -c 4 8.8.8.8

Código Selecionar Expandir
ping -c 4 www.google.com

Além disso, suba o sistema usando um live-iso de 64-bit e veja se a conexão funciona ou não, é o tira-teima.

Olá druida,
eu testei diversas configurações de IP que um amigo me passou (IPv4, DHCP manual) e nenhuma tinha funcionado antes.
Como sou leigo vou testando as dicas que me passam pra conseguir resolver o problema.
Se houve alguma mudança no roteador, foi feita a partir de algum comando que recebi neste fórum.

Vou tentar instalar o 64 bits mais tarde pra comparar.

Enquanto isso, envio o resultado dos comandos que você passou:

mateus@mateus-hst:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
mateus@mateus-hst:~$ sudo lshw -c network
[sudo] senha para mateus:
*-network
descrição: Ethernet interface
produto: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
fabricante: Realtek Semiconductor Co., Ltd.
ID físico: 0
informações do barramento: pci@0000:05:00.0
nome lógico: enp5s0
versão: 06
serial: 74:d4:35:e1:53:ee
tamanho: 100Mbit/s
capacidade: 1Gbit/s
largura: 64 bits
clock: 33MHz
capacidades: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuração: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.0.104 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
recursos: irq:29 porta de E/S:b000(tamanho=256) memória:fe100000-fe100fff memória:da100000-da103fff
mateus@mateus-hst:~$ ifconfig -a
enp5s0 Link encap:Ethernet Endereço de HW 74:d4:35:e1:53:ee
inet end.: 192.168.0.104 Bcast:192.168.0.255 Masc:255.255.255.0
endereço inet6: fe80::b85a:fa5d:746b:b0ef/64 Escopo:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1
pacotes RX:4339669 erros:0 descartados:0 excesso:0 quadro:0
Pacotes TX:3312434 erros:0 descartados:0 excesso:0 portadora:0
colisões:0 txqueuelen:1000
RX bytes:5192313620 (5.1 GB) TX bytes:703732041 (703.7 MB)

lo Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACK RUNNING MTU:65536 Métrica:1
pacotes RX:14011 erros:0 descartados:0 excesso:0 quadro:0
Pacotes TX:14011 erros:0 descartados:0 excesso:0 portadora:0
colisões:0 txqueuelen:1
RX bytes:1394710 (1.3 MB) TX bytes:1394710 (1.3 MB)

mateus@mateus-hst:~$ nmcli d show
GENERAL.DISPOSITIVO: enp5s0
GENERAL.TIPO: ethernet
GENERAL.ENDEREÇO-HW: 74:D4:35:E1:53:EE
GENERAL.MTU: 1500
GENERAL.ESTADO: 100 (conectado)
GENERAL.CONEXÃO: Conexão cabeada 1
GENERAL.CAMINHO CON: /org/freedesktop/NetworkManager/ActiveConnection/0
WIRED-PROPERTIES.PROVEDOR: ligado
IP4.ENDEREÇO[1]: 192.168.0.104/24
IP4.MÁQUINA: 192.168.0.1
IP4.ROTA[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]: 192.168.0.1
IP6.ENDEREÇO[1]: fe80::b85a:fa5d:746b:b0ef/64
IP6.MÁQUINA:

GENERAL.DISPOSITIVO: lo
GENERAL.TIPO: loopback
GENERAL.ENDEREÇO-HW: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.ESTADO: 10 (não gerenciável)
GENERAL.CONEXÃO: --
GENERAL.CAMINHO CON: --
IP4.ENDEREÇO[1]: 127.0.0.1/8
IP4.MÁQUINA:
IP6.ENDEREÇO[1]: ::1/128
IP6.MÁQUINA:
mateus@mateus-hst:~$ ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=29 time=4.28 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=29 time=3.53 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=29 time=1.93 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=29 time=2.03 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.937/2.947/4.287/1.001 ms
mateus@mateus-hst:~$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.

56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=223 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=358 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=387 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=275 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 223.145/310.868/387.127/65.229 ms
mateus@mateus-hst:~$ ping -c 4 www.google.com
PING www.google.com (172.217.28.36) 56(84) bytes of data.
64 bytes from eze03s16-in-f4.1e100.net (172.217.28.36): icmp_seq=1 ttl=52 time=420 ms
64 bytes from eze03s16-in-f4.1e100.net (172.217.28.36): icmp_seq=2 ttl=52 time=643 ms
64 bytes from eze03s16-in-f4.1e100.net (172.217.28.36): icmp_seq=3 ttl=52 time=498 ms
64 bytes from eze03s16-in-f4.1e100.net (172.217.28.36): icmp_seq=4 ttl=52 time=466 ms

--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 420.349/507.159/643.363/83.424 ms

zekkerj · 31 de Julho de 2016, 13:00

Citação de: druidaobelix online 31 de Julho de 2016, 04:48
Isso apenas não faz o menor sentido, basta que se faça o retrospecto de tudo quanto se conversou neste tópico e das providência que você disse que fez, inclusive fazendo instalações "limpas" sucessivas das versões 14.04 e da 16.04.

Pra mim faz muito sentido. A máquina dele é antiga, de alguma forma não funciona corretamente em 64 bits.
Ou o ISO de 64 bits que ele baixou estava corrompido...

Acho que você está exagerando um pouco com a atribuição de IP. A implementação do servidor DHCP não é obrigada a seguir nenhuma ordem específica, enquanto uns começam a atribuir do número mais baixo, outros podem atribuir do número mais alto, e um terceiro pode oferecer aleatoriamente dentro da faixa, ou ainda a partir de uma função de hash com base no MAC Address. Ou seja, nada impede que a máquina dele tenha sido a primeira da rede e ainda assim receber o IP com final 20. Com o detalhe que a máquina dele não é nem a única, nem a primeira.

Eu sou da opinião que quem precisa da máquina funcionando não pode ser dar muito ao luxo de ficar fuçando. Descobrir porque alguma coisa funciona ou não funciona é legal, mas melhor ainda é poder curtir seu equipamento.