O laptop Toshiba WinXP não consegue adquirir (DHCPREQUEST) novo IP após conexão a rede diferente

Question

Meu laptop é um Toshiba Satellite Pro com o francês Win XP SP3 com todas as atualizações atuais; Toshiba inclui uma ferramenta de software "ConfigFree" para a rápida mudança de parâmetros de rede.

Até ~ dezembro funcionou bem, o DHCP em mais de três redes diferentes (redes com fio em duas universidades e em casa, bem como algumas WLANs) sempre adquiriam um endereço IP corretamente; Não precisei alterar nenhum parâmetro da rede. Aproximadamente desde que me mudei para um novo flat (onde um novo modem e roteador DSL foi instalado), estou tendo um problema estranho (que pode acontecer de coincidir com o movimento).

Após a reinicialização, a máquina sempre adquire um endereço DHCP corretamente. Mas se eu colocá-lo em modo de espera enquanto eu estiver no Laboratório A e levá-lo para casa ou para Laboratório B , ele não conseguirá mudar para a nova rede. Isso significa que o laptop envia DHCPDISCOVER, o servidor DHCP envia DHCPOFFER, mas nunca recebe um DHCPREQUEST do laptop. O laptop parece estar surdo para a resposta do servidor e continua tentando por um tempo antes de atribuir um endereço 168.x.x.x inútil. "Reparando" a conexão não funciona, nem ipconfig / renew. Desativar / reativar a placa de rede não ajuda. A reinicialização ajuda, mas eu gostaria de entender o que está errado para que eu possa consertá-lo.

O mesmo problema ocorre em redes diferentes com as quais eu consegui me conectar com êxito (sem reinicialização) até alguns meses atrás, mas não me lembro de alterar nada na minha máquina, além de permitir atualizações de software semiautomáticas (Windows etc). Eu analisei sistematicamente apenas para conexões ethernet com fio, mas eu vi o mesmo problema acontecendo para um túnel VPN (FortiClient) e conexões sem fio.

Quando o DHCP falhou, posso manualmente (ou usando a ferramenta FreeConfig, veja acima) mudar para um IP estático (se por acaso eu souber qual faixa escolher); Eu usei com sucesso esta solução por um tempo agora, uma vez que evita a reinicialização. Mais tarde, poderei voltar ao modo de espera, voltar ao laboratório A (onde o laptop foi inicialmente inicializado), voltar para o DHCP sem problemas.

Atualizar

Eu reflashed o BIOS mesmo sabendo que ele estava atualizado, então reinstalei o & atualizou os drivers de rede (placa de rede e sem fio). Eu redefinir o TCP / IP usando netsh int ip reset c:\resetlog.txt e Winsock usando netsh winsock reset como sugerido neste post SU . O antigo comando removeu alguma integração com a minha solução Firewall / VPNClient / Antivirus FortiClient, então tive que reinstalá-lo para que o IPSEC VPN funcionasse novamente. Depois de tudo isso, o problema parece ter diminuído - o DHCP agora funciona na primeira reconexão após o standby.

Se eu desconectar / reconectar o cabo de rede em casa (ou desligar a transmissão sem fio e ligá-lo novamente), o dispositivo correspondente exibirá os mesmos sintomas antigos (sem DHCP) novamente, mesmo que tenha funcionado pela primeira vez alguns segundos atrás. Reinstalar o driver de rede me dá outra chance de adquirir um IP; -).

Depois de um pouco mais de brincadeira, percebi que esse problema remanescente realmente parece ser causado pelo Firewall no FortiClient - desativá-lo temporariamente resolve o problema. Então eu acho que vou entrar em contato com a empresa Fortinet para ver o que eles têm a dizer sobre isso ...

    

Answer 1

Soa como um problema de driver. No mínimo, reinstale o driver original. Um patch pode ter mudado sua configuração ou dependências.

Idealmente, atualize seus drivers da placa-mãe (chipset) e seus drivers de rede e veja o que isso faz.

Além disso, a rede integrada do Windows tem a capacidade de alternar redes, armazenar com segurança vários perfis sem fio em uma lista ordenada por preferências e praticamente tudo o mais útil que o aplicativo ConfigFree da Toshiba tentou fazer. Eu ainda não encontrei um add-on ou aplicativo OEM (cada fabricante de hardware tem esses aplicativos de bloatware carregados em suas máquinas agora) que faz mais do que o Windows com diferença suficiente para compensar o custo de executar esses recursos. do que aplicativos com experiência em funções.

Eu recomendaria remover o aplicativo ConfigFree. Você sempre pode fazer o download da versão mais recente e reinstalá-la se achar que ela possui funções absolutamente necessárias. Mas se você está apenas navegando entre três redes diferentes, o Windows pode lidar com isso sozinho.

Além disso, será um ponto de falha menos possível na solução de problemas.

Finalmente, na minha experiência, os drivers e o modo de espera ou a hibernação são menores do que os amigos do busom. O fato de que eles trabalharam antes significa que eles devem funcionar agora, mas as diferenças nos estados de energia suportados por vários motoristas podem causar uma frustração incalculável. Eu encontrei a maioria dos problemas com laptops ocorrem com laptops em hibernação ou stand-by sendo desencaixados, que é uma mudança de hardware relativamente significativa para um sistema essencialmente pausado. Mas as mudanças na rede também causaram problemas.