Localhost (Raspberry Pi) se recusa a conectar-se a um dos dois PCs na rede local (WiFi)

0

Estou na minha segunda tentativa de configurar um servidor da Web LAMP ( link ) na minha LAN. A primeira tentativa foi bem sucedida até que repentinamente percebi que o servidor recusava a conexão com o meu laptop (Windows 10) - já havia sido conectado com sucesso. Eventualmente, em desespero enxugou Pi e começou de novo, testando cuidadosamente passo a passo. Então, tendo conectado Pi ao WiFi (ping do laptop OK), o primeiro passo é instalar o Apache2. Tudo bem, e a página Apache2 Debian Default aparece no navegador do Pi em resposta ao link (endereço IP do Pi). Como esperado.

Neste estágio, meu laptop (chamada de laptop1) não tem conexão com o endereço IP. Mas checando um segundo PC (laptop2 rodando o XP), nós nos conectamos à página padrão do Apache2 Debian como esperado. Laptop1, laptop2 e Pi estão todos no mesmo WiFi.

Eu NÃO fiz outras alterações no Pi ou em qualquer laptop.

Eu concluo: A instalação do Apache está bem. A dificuldade está no laptop1.

Alguém pode sugerir como posso rastrear isso no laptop1? Onde devo começar a procurar? É um cenário que eu inadvertidamente mudei? Uma dll pode ter sido corrompida?

Adicionado depois: o log de acesso do Apache mostra dois códigos de erro associados ao laptop1. estes são 404 (não encontrados) e 408 (Desperdício de tempo, leitura errada do prefixo 407 Proxy). Então, por que o laptop1 não foi encontrado?

Obrigado, John

    
por user30578 30.08.2018 / 18:08

1 resposta

0

O problema desapareceu quando limpei cookies do navegador Chrome no Laptop1, mas não entendi o motivo. Obrigado RalfFriedel por sugerir o tcpdump - aprendi muito brincando com ele, mas não ajudou muito a diagnosticar o problema. Os rastros do laptop1 (conexão recusada) eram muito diferentes do laptop2 (a página padrão do Apache era exibida corretamente). O rastreamento do laptop1 não mudou muito agora que está conectando OK, então continuo perplexa! Eu estou supondo aqui (talvez alguém possa me classificar), mas parece que o tcpdump está olhando em torno das camadas de transporte / rede, enquanto o meu problema foi, provavelmente, no nível do aplicativo?

De qualquer forma, o problema desapareceu. Mas não resolvido. João

    
por 01.09.2018 / 11:34