A máquina SuSE transmite para o dhcp antes que o link esteja pronto

3

A máquina está executando o SuSE 11.2. Eu configurei para conectar usando DHCP usando a interface de rede gráfica do YaST2.

Quando eu dhcpcd -k eth0 e, em seguida, dhcpcd eth0 , recebo uma concessão quase instantaneamente e tudo fica bem. No entanto, se eu ifdown eth0 e, em seguida, ifup eth0 , não obtenho um endereço IP por aproximadamente 20 segundos. Observar o fluxo de pacotes de rede revela que, no cenário ifdown / up, uma solicitação dhcp é transmitida com êxito, mas nenhuma resposta chega.
EDIT: A mesma coisa acontece durante a inicialização. Um pacote de transmissão é enviado antes de o link se tornar ativo.

/ var / log / messages revela o seguinte:

Dec 6 14:21:50 olm ifup: eth0 device: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)
Dec 6 14:21:51 olm kernel: [ 3389.717366] tg3 0000:02:00.0: PME# disabled
Dec 6 14:21:51 olm kernel: [ 3389.936570] ADDRCONF(NETDEV_UP): eth0: link is not ready
Dec 6 14:21:51 olm ifup-dhcp: Starting DHCP4 client on eth0
Dec 6 14:21:51 olm dhcpcd[11807]: eth0: dhcpcd 3.2.3 starting
Dec 6 14:21:51 olm dhcpcd[11807]: eth0: hardware address = 00:10:18:30:60:3c
Dec 6 14:21:51 olm dhcpcd[11807]: eth0: broadcasting for a lease
Dec 6 14:21:51 olm ifup-dhcp: .
Dec 6 14:21:53 olm kernel: [ 3392.126437] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Dec 6 14:21:53 olm kernel: [ 3392.126441] tg3: eth0: Flow control is on for TX and on for RX.
Dec 6 14:21:53 olm kernel: [ 3392.127000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec 6 14:21:54 olm ifup-dhcp: .
Dec 6 14:21:55 olm avahi-daemon[3414]: Registering new address record for fe80::210:18ff:fe30:603c on eth0.*.
Dec 6 14:21:57 olm ifup-dhcp: .
Dec 6 14:21:59 olm ifup-dhcp:
Dec 6 14:21:59 olm ifup-dhcp: eth0 DHCP4 continues in background
Dec 6 14:22:04 olm kernel: [ 3403.004015] eth0: no IPv6 routers present
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: timed out
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: trying to use old lease in '/var/lib/dhcpcd/dhcpcd-eth0.info'
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: adding IP address 172.26.59.123/26
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: adding default route via 172.26.59.65 metric 0

É importante observar que o dhcpcd transmite para uma concessão antes que o link eth0 esteja pronto. Nunca recebe uma resposta porque a transmissão nunca chegou a lugar nenhum.

Então, minha pergunta é: Por que o ifup-dhcp inicia o processo DHCP antes que o link esteja pronto? e como posso fazer isso esperar corretamente?

    
por Myrn 06.12.2010 / 21:56

2 respostas

2

Descobri o motivo pelo qual ele solicita um contrato antes que o link esteja pronto. É porque o ifup-dhcp tenta esperar até que a interface esteja pronta antes de chamar o dhcpcd, mas usa a função is_iface_up que é definida em /etc/sysconfig/network/scripts/functions , e essa função apenas verifica se eth0 existe antes de retornar um resultado positivo.

Eu também encontrei uma solução (ligeiramente) mais a longo prazo. ifup-dhcp espera por um resultado positivo de is_iface_up e então espera uma quantidade adicional de segundos, conforme definido por DHCLIENT_SLEEP, que pode ser encontrado em / etc / sysconfig / network / dhcp. Definindo DHCLIENT_SLEEP="3", a interface agora tem tempo para ficar pronta antes de o dhcpcd ser chamado, apesar do fato de que is_iface_up retorna muito cedo. Isso também é menos provável de ser espancado por atualizações.

    
por 07.12.2010 / 18:34
0

Se a caixa estiver em uma rede com árvore de abrangência, pode ser o atraso para o link se tornar ativo. Isso não deve ser um problema durante uma reinicialização, mas será para uma operação de parada / início. Você sempre pode colocar um sono no script ifup, mas isso é meio que um hack. Outra opção seria escrever em alguma lógica para o script ifup verificar o status do link antes de fazer a chamada dhcp. Link pode ser verificado com ethtool. Ou você poderia apenas aumentar o tempo limite do cliente dhcp. A modificação do script ifup é sujeita a sobregravação por atualizações.

    
por 06.12.2010 / 22:14

Tags