De 192.168.0.146 icmp_seq = 1 Host de destino inacessível [fechado]

Question

root@prateek-desktop:~# ping 192.168.0.1 
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.146 icmp_seq=1 Destination Host Unreachable
From 192.168.0.146 icmp_seq=2 Destination Host Unreachable
From 192.168.0.146 icmp_seq=3 Destination Host Unreachable

root@prateek-desktop:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

Qual pode ser a razão provável por trás de não conseguir fazer ping? O firewall foi desativado ... e 192.168.0.1 é o endereço IP do meu roteador sem fio que está habilitado para DHCP. Não a porta ethernet para esse roteador tem endereço IP atribuído pelo DHCP e meu pc tem endereço IP 192.168.0.146 ambos estão tendo mesma rede e meu pc tem gateway padrão nas configurações de rede atribuído como 192.168.0.146. Apesar disso meus outros dispositivos podem pingar meu pc, mas meu pc não pode pingar qualquer outro dispositivo, incluindo o roteador ao qual o meu pc está conectado diretamente.

    

Answer 1

Pode haver uma de quinze bilhões de razões. Alguns deles estão listados abaixo:

• Problema de configuração de rede na sua área de trabalho. (Você configurou o Gateway apropriado?)
• Firewall do sistema de destino configurado para NÃO responder a pings
• Cabo de rede incorreto conectando você à rede
• Seu sistema tem regras de firewall que bloqueiam respostas de ICMP de outros hosts
• A configuração de firewall em toda a rede filtra o ICMP (inclui configurações de switch)

O problema é que, com apenas as informações fornecidas, não há absolutamente nenhuma maneira de fazer mais diagnósticos, tornando essa questão "muito ampla" (marcada como tal).

    

Answer 2

What can be the probable reason behind not able to ping?

     

AfroJoe: muitas razões

Esta é uma informação muito limitada. É possível afirmar apenas uma razão provável a partir disso. Descobri que conhecer essa razão é útil em pouquíssimas situações. Uma dessas situações aconteceu exatamente porque eu soube o suficiente para interferir comigo mesmo.

A linha "Destination Host Unreachable" quase certamente significa que seu próprio host é 192.168.0.146 e a resolução ARP está falhando. Para confirmar:

$ ping 172.16.8.2
PING 172.16.8.2 (172.16.8.2) 56(84) bytes of data.
From 172.16.8.205 icmp_seq=1 Destination Host Unreachable
From 172.16.8.205 icmp_seq=2 Destination Host Unreachable
From 172.16.8.205 icmp_seq=3 Destination Host Unreachable
^C
--- 172.16.8.2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms
pipe 4

$ ip -4 neigh
172.16.8.1 dev wlp2s0 lladdr 74:44:01:86:42:d6 REACHABLE
172.16.8.2 dev wlp2s0  INCOMPLETE

A resolução bem-sucedida do ARP envolve uma troca como esta:

$ sudo tcpdump -n -i wlp2s0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
...
13:43:49.469349 ARP, Request who-has 172.16.8.1 tell 172.16.8.205, length 28
13:43:49.470046 ARP, Reply 172.16.8.1 is-at 74:44:01:86:42:d6, length 28
13:43:49.852608 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 21, length 64
13:43:49.854600 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 21, length 64
13:43:50.853879 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 22, length 64
13:43:50.855867 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 22, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

(obtido durante a execução do ping e forçando uma atualização do ARP usando ip neigh flush dev wlp2s0 ).

Por que a resolução ARP falha, você pergunta?

AfroJoe: so many reasons

Eu tenho uma outra parte do conhecimento secreto. A menos que o sistema cliente do Ubuntu tenha sido deliberadamente configurado por alguém, o endereço 192.168.0.146 foi atribuído por meio de uma troca de pacotes DHCP. Normalmente, essa troca envolveria o roteador, embora também envolva um Windows Server ou, possivelmente, outro servidor (espero que os administradores do Windows sejam ensinados a retransmitir DHCP pelo roteador). Neste caso, onde o roteador é o servidor DHCP ou retransmissão, seu sistema já conseguiu trocar alguns pacotes com o roteador .

Você pode testar a reativação da troca de DHCP interrompendo e refazendo a conexão. (Embora a Apple tenha escrito uma otimização, que também pode renovar após uma troca de pacotes ARP específicos .) É claro que se o problema persistir de volta "aleatoriamente", isso não resolve o problema subjacente, e você pode querer investigar a conexão enquanto ela ainda está quebrada.

É comum ver isso com uma conexão usando DHCP e WiFi, quando o sinal sem fio é perdido em algum momento. (E você percebe isso antes da camada sem fio ter desistido completamente ... Eu não sei por que eu vi isso tantas vezes, talvez eu estivesse observando sistemas com erros ou mal escritos). Mas eth1 não é uma conexão WiFi.

Acredito que o DHCP para IPv4 opera sem a necessidade de qualquer ARP. Pelo menos quando o sistema do cliente traz sua interface pela primeira vez.

Conclusão

Dos fatos na versão inicial de sua pergunta, luto para pensar em qualquer cenário individual que seja particularmente comum. (Incluindo minhas suposições implícitas. É improvável que alguém publique essa pergunta sem tentar conectar seu computador a um roteador operacional).

• A rede à qual você está conectado não tem dispositivo com o endereço 192.168.0.1 . Se foi isso que lhe deu um endereço DHCP, ele foi removido da rede. Desconectado ou simplesmente morreu.
• Você configurou a eth1 manualmente E um dos
  • você não está usando o NetworkManager no Ubuntu Desktop e
    • você não tem um link Ethernet detectado (verifique ethtool ).
    • Ou você tem um link de ethernet detectado, mas o switch exige que você forneça uma senha ou outra autenticação usando 802.1X .
    • Ou você tem um link de ethernet detectado, mas é necessário registrar o endereço MAC do seu computador com o administrador da rede.
  • você tem um cabo que funciona bem o suficiente para detectar um link, mas não o suficiente para transportar pacotes de dados com segurança.