agora incapaz de obter o endereço IP do DHCP no modem - o que mudou?

Question

Eu tenho um modem DSL que faz o DHCP, que parece ser saudável, porque eu posso conectar outros hosts a ele e obter endereços IP, mas não meu computador normal.

Após estar ausente por semana, ao inicializar, não foi possível obter um endereço IP. Eu tentei tudo de novo e ele conseguiu um endereço IP, no entanto foi muito lento ou derrubando a maioria dos pacotes e eu não poderia usá-lo para navegar na web.

Outras reinicializações e ciclos ifdown / ifup apenas falham imediatamente.

Eu sei que não é o modem ou o cabo porque outros PCs podem se conectar.

Eu não acho que seja o NIC porque eu tenho um segundo NIC que também não obtém um endereço IP.

Eu desativei o firewall também, o que não ajudou.

Ele está rodando 16.04.3

Meu único palpite é que eu atualizei um pacote de rede que agora requer algum ajuste - talvez dhclient. Eu não estou executando o network-manager, isso é uma configuração básica.

Não há nada nos logs, exceto algo nos moldes disso (copiado da tela manualmente):

Sep 8  23:40:27 gondor kernel: [ 495.11235] e1000e: enp0s25 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 8  23:40:27 gondor kernel: [ 495.11235] e1000e: enp0s25 NIC Link is Down

que é repetido várias vezes enquanto o ifup está sendo executado.

Poderia ter destruído minha configuração de rede instalando ou atualizando um pacote?

/ etc / network / interfaces:

auto lo
iface lo inet loopback

auto enp0s25
allow-hotplug enp0s25
iface enp0s25 inet dhcp

[UPDATE] lshw -C network output conforme solicitado:

  *-network               
       description: Ethernet interface
       product: 82567LF Gigabit Network Connection
       vendor: Intel Corporation
       physical id: 19
       bus info: pci@0000:00:19.0
       logical name: enp0s25
       version: 03
       serial: 00:01:80:76:c5:39
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=1.8-3 ip=86.139.80.140 latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
       resources: irq:25 memory:fdfc0000-fdfdffff memory:fdfff000-fdffffff ioport:fe00(size=32)

    

Answer 1

Seu problema é com a configuração de MTU para sua conexão DSL.

Para DSL, uma configuração de MTU comum é 1492. Basta ir em frente e tentar este valor primeiro e ver se os seus sites estão agora acessíveis.

Para determinar a configuração correta, comece com todas as configurações de MTU = 1500 e VPN = off. (VPN requer testes diferentes).

No terminal:

ping [-c count] [-M do] [-s packet_size] [host]

As opções usadas são:

• c count : número de vezes para pingar
• M hint : selecione a estratégia de descoberta do MTU do caminho. pode ser do (proibir fragmentação, mesmo local), want (fazer descoberta de PMTU, fragmentar localmente quando o tamanho do pacote é grande) ou dont (não definir sinalizador DF).
• s packet_size : especifica o número de bytes de dados a serem enviados.

Você deve sempre começar em 1472 e diminuir 10 vezes a cada vez. Depois de receber uma resposta, suba até 1 até obter um pacote fragmentado. Pegue esse valor (último valor bom) e adicione 28 ao valor para considerar os vários cabeçalhos TCP / IP. Por exemplo. Digamos que 1452 tenha o tamanho adequado do pacote (onde você obteve uma resposta ICMP ao seu ping). O tamanho real da MTU seria 1480, que é o ideal para a rede com a qual estamos trabalhando.

ping -c 4 -M do -s 1472 8.8.8.8 # this will probably show fragmentation

ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation

ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?

ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?

referência: Como determinar o correto Tamanho da MTU com pings ICMP