Rede eth0 DHCP, ip estático e problemas de negociação automática

6

Plano de fundo

Estou executando um servidor Ubuntu em 14.04, que está atualmente atualizado. Eu tenho apenas um dispositivo de rede conectado a ele. Quando uso meu cabo Ethernet e o conecto da parede ao meu laptop (executando o Windows 7), o DHCP resolve sem problemas.

Problema

Quando conecto meu cabo Ethernet da parede ao meu servidor (executando o Ubuntu) e ligo o meu servidor, o servidor DHCP não atribui ao meu servidor um endereço IP. No entanto, quando eu conecto o cabo do meu servidor ao meu laptop usando a Ethernet dos laptops conectada para conectar através da minha conexão Wifi, o servidor receberá um endereço IP do DHCP através do laptop. Por fim, depois que recebo um IP da conexão do laptop, uso os seguintes comandos e, em seguida, o DHCP funciona quando o cabo é conectado da parede ao servidor:

sudo dhclient -r
sudo dhclient -v eth0

Da próxima vez que eu reiniciar o servidor via sudo shutdown -r now , o servidor não poderá obter um IP novamente do DHCP com o cabo da parede para o servidor.

Observe que, quando eu atribuo um endereço estático no arquivo /etc/network/interfaces , a rede não atribui o IP e a interface fica inativa.

Pergunta

Existe uma maneira de corrigir o problema que estou tendo com a minha rede não sendo capaz de descobrir o servidor DHCP quando eu ligar o servidor?

Se você precisar de mais informações, por favor me avise.

Informações adicionais

dhclient antes de conectar ao laptop

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 (xid=0x********)
...
No DHCPOFFERS received
No working leases in persistent database - sleeping.

dhclient com servidor conectado ao laptop

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x*********)
DHCPREQUEST of 192.168.137.233 on eth0 to 255.255.255.255 port 67 (xid=0x*********)
DHCPOFFER of 192.168.137.233 from 192.168.137.1
DHCPACK of 192.168.137.233 from 192.168.137.1
bound to 192.168.137.233 -- renewal in 275 seconds.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:22:64:23:7c:da  
          inet addr:192.168.137.233  Bcast:192.168.137.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28265 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2781 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4655957 (4.6 MB)  TX bytes:415144 (415.1 KB)

dhclient após laptop DHCP e cabo reconectado da parede ao servidor

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x********)
DHCPREQUEST of 192.168.1.126 on eth0 to 255.255.255.255 port 67 (xid=0x*******)
DHCPOFFER of 192.168.1.126 from 192.168.1.254
DHCPACK of 192.168.1.126 from 192.168.1.154
bound to 192.168.1.126 -- renewal in 41950 second.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:22:64:23:7c:da  
          inet addr:192.168.1.126  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33438 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3391 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5245215 (5.2 MB)  TX bytes:550462 (550.4 KB)

interface de rede (lshw)

sudo lshw -class network

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: eth0
       version: 02
       serial: 00:22:64:23:7c:da
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.82 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:42 ioport:e800(size=256) memory:febff000-febfffff memory:fdff0000-fdffffff memory:febc0000-febdffff

Atualização:

Meu arquivo /etc/network/interfaces é como tal

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Encontrei uma correção temporária que parece funcionar, mas não gostaria que fosse a minha solução se pudéssemos resolver esse problema. Eu mudei o arquivo de interfaces como assim

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
    pre-up ifconfig $IFACE up
    pre-up mii-tool -R

Isso (acredito) diz à interface para resetar e por alguma razão isso permitiu que o DHCP resolvesse como deveria. Como eu disse, tem que haver uma correção real fora desta.

Solução:

Com a ajuda da resposta da Fabbys, consegui encontrar uma solução mais viável com a qual eu possa conviver.

Abra / etc / network / interfaces e configure a interface ethernet de uma destas maneiras:

DHCP

auto eth0
iface eth0 inet dhcp
    pre-up ifconfig $IFACE up
    pre-up ethtool -s $IFACE speed 100 duplex full autoneg off

Estática

auto eth0
iface eth0 inet static
    post-up ethtool -s $IFACE speed 100 duplex full autoneg off
    address x.x.x.x #Internal IP
    netmask 255.255.255.0
    gateway x.x.x.y #Gateway IP
    dns-nameservers 8.8.8.8 #Google DNS

Espero que isso ajude alguém no futuro.

    
por Mic1780 19.01.2015 / 20:42

2 respostas

4

Conforme a discussão no bate-papo, desative a negociação automática no servidor e corrija a velocidade da rede ao nível mais alto que a placa de interface de rede (NIC) pode suportar.

Comece com 10Mbps, half duplex e trabalhe para cima para 10Mbps FD, 100Mbps HD, ... até o problema começar. Então desça um ponto e deixe-o nessa velocidade.

Primeiro, instale ethtool (se já instalado, você receberá um aviso de que a versão mais recente já está instalada)

sudo apt-get install ethtool

Agora:

  1. Digite o seguinte comando (e teste-os um por um)

    sudo ethtool --change eth0 speed xxx duplex yyy autoneg off
    

    em que xxx = 10 , 100 ou 1000 e yyy = half ou full .

    Portanto, comece com 10 half , 10 full , 100 half , ...

  2. Faça um ifconfig para verificar se você recebeu um endereço IP.

  3. Volte para 1 até que pare de funcionar e use os valores anteriores que ainda funcionavam para:

  4. Para tornar a mudança permanente , execute o seguinte comando:

    sudo nano /etc/network/interfaces
    

    e digite na seção pre-up :

    pre-up /usr/sbin/ethtool --change eth0 speed xxx duplex yyy autoneg off 
    
por Fabby 22.01.2015 / 01:22
0

OH HOMEM FACEPALM (facepalm para mim como eu pensava originalmente neste segundo em vez do primeiro como deveria ter é quase sempre as coisas mais simples que podem fazer você andar em círculos com a tecnologia, eh ?)

(movido para o topo, já que este é provavelmente o problema, mas deixou o outro conteúdo abaixo para referência).

Se você está usando o mesmo fio para conectar seu servidor ao seu laptop, você é seu servidor na parede. É PROVÁVEL O PROBLEMA !! (mais uma vez, este é mais o meu erro por perder este primeiro e só pensando nisso em segundo lugar. Eu não queria me deparar com algo áspero se é assim que soa)

Existem dois tipos diferentes de fios que você está usando aqui ...

Referência: link

Primeiro, é um cabo ethernet Straight Through usado para switches e roteadores para computadores clientes

O segundo é um cabo cruzado: eles são usados para conexões máquina a máquina e são fisicamente conectados de maneira diferente!

Portanto, se esses cabos funcionam entre o seu servidor e o laptop sem nenhum switch ou roteador entre os 2 (a conexão Wi-Fi NÃO conta aqui para nada), o cabo precisa ser um ponto de passagem.

Obtenha um cabo padrão direto e conecte-se do roteador ao servidor e veja o que acontece.

Na minha experiência, os problemas do computador resumem-se ao mais simples dos problemas com overloook. Alguns roteadores e switches são "inteligentes" e podem tentar fazer ajustes internos quando você usa o cabo incorreto (crossover) para que você ainda possa usá-lo para conectar a máquina, mas isso nunca é algo para se confiar e é mais provável que seja o questão.

Na verdade, isso soa como um problema no roteador. Eu, por exemplo, tenho FiOS e no roteador eu posso ir e olhar para as configurações de rede e vejo onde ele conecta os segmentos WiFi e Wired separadamente ao servidor DHCP, então se algo acontecer a essa configuração eu poderia acabar com o que você tem aqui você não pode mais obter um IP over the Wire, pois ele não está conectado à rede "Home" que está executando o servidor DHCP, mas você pode usar o WiFi enquanto ainda estiver conectado à rede "doméstica" do roteador. Você pode tentar olhar através das configurações avançadas do seu roteador ou mais frequentemente do que não se você tiver um clipe de papel e há um botão de reset, você pode procurar como redefinição de fábrica (geralmente segure clipe de papel por 30 segundos ).

Além disso, seu laptop está recebendo um IP via WiFi Only. Se você tem uma máquina e tem um adaptador com fio e wi-fi e você tem Wi-Fi conectado e conecte um fio mesmo se isso falhar, sua máquina ainda vai navegar na internet e o que não causar isso é rotear todos os pedidos via WiFi e ignorar o porta com fio completamente.

Sua "correção" funciona porque você está solicitando um IP por meio do adaptador Wifi de laptops no final.

De ler mais aqui, também percebo que talvez um recurso de segurança MAC esteja habilitado no roteador ... Isso significa que, a menos que o endereço MAC da NIC esteja dentro da lista permitida de clientes, seu roteador se recusaria a fornecer um endereço . Você pode "consertar isso primeiro passando pelo laptop que está na lista e uma vez que você tenha um endereço assim quando se conectar de volta à parede e lançar outro pedido, ele pode pular a verificação do MAC, já que ele já lhe deu um endereço e, pelo menos, acha que o seu servidor é um cliente confiável. Eu também verificaria qualquer segurança MAC ativada dentro do roteador.

Eu não estou dizendo que é impossível que o servidor DHCP dos roteadores tenha algum problema estranho, mas isso seria SOO SUPER RARRA. Não posso dizer o quanto é raro.

    
por Mike 21.11.2016 / 18:31