This page has been translated from Italian
December
30

Why does my ADSL does not work

| 2 commenti | TrackBack | | | 2 comments | TrackBack |
una stelladue stelletre stellequattro stellecinque stelle (Rate this article!)
Loading ... Loading ...
Bookmark and Share

Today, we try to figure out how to do when our DSL is wrong. Often I happen to be called at work or friends who complain that Internet does not work. So that the problem is difficult to interpret because there may be many reasons why an ADSL line that runs up to a minute it stops working hours.

Yet there is a very simple checklist to verify and isolate at what point does not work and if it is appropriate to make a report to the operator or if the issue has nothing to do with the various Alice, Tiscali, Infostrada, whatever you want .

Recall that often these operators, Telecom in the first place, if they come home and claim that the call was made for an issue not directly attributable to them, you are paying for the call.

Let's see to understand, in this article, the steps to check the breakpoint of our Internet line.

Just remember one thing, if a test fails NOT go ahead. Before you can go on the previous step must have been successful.

First we start from the assumption that you have a Windows machine even if the commands that we use are, with the same name, even on mac and linux terminal.

The first thing to do is open the environment that we use for our tests that the " command prompt ".

Test 1 - Ping the loopback interface

First, we use the ping command. The ping command does is send a small packet to a remote IP address. If the remote PC has activated the service table, and almost everyone has it, unless it is filtered by some firewall, the remote PC will respond to our table with a response packet.

The ping command will tell us then if someone is on the other hand, we said, is how long it took between demand and response.

The first test uses precisely the ping command, but on a particular IP address that the remote has very little. The address in question is also called the loopback address 127.0.0.1. In fact, all systems are running the TCP / IP, which is the protocol with which the Internet works, have a network interface virtual loopback call to respond locally to this particular address.

This first test then verifies that all TCP / IP of our machine is installed and functioning properly and must obviously operate independently of the fact that our PC is on or off to some kind of network. The loopback address must always answer unless you have a problem with the libraries of the operating system The Manage the TCP / IP.

I therefore command

ping 127.0.0.1

si deve ottenere qualcosa del genere:

ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

Questo è il risultato corretto da ottenere che, a parte i valori in millisecondi di risposta, indica comunque che l’interfaccia di loopback è funzionante e risponde.

Una risposta diversa, in particolare un messaggio di errore hardware o comunque una mancata risposta al ping sta ad indicare che: o lo stack TCP/IP non è configurato o non è abilitato o che, qualcosa, un virus o un settore del disco difettoso, ha corrotto le librerie che stanno alla base del funzionamento di questo protocollo sul vostro PC.

Test 2 – La rete è connessa?

La seconda verifica è controllare se siamo collegati ad una rete e se abbiamo un indirizzo IP “giusto”.

Per fare questo utilizziamo un altro comando del “prompt” chiamato ipconfig. Questo comando ci da informazioni su tutte le schede di rete su cui è abilitato il TCP/IP.

In particolare dovremo vedere se la scheda di rete “principale” o quella wireless è collegata e ha un indirizzo IP “giusto”.

Per questo vi serve un po’ di abilità nel riconoscere la scheda di rete giusta. Vediamo un esempio del comando ipconfig sul mio portatile. Il risultato del comando è

Configurazione IP di Windows
Scheda Ethernet VMware Network Adapter VMnet8:

 Suffisso DNS specifico per connessione:
 Indirizzo IP. . . . . . . . . . . . . : 192.168.49.1
 Subnet mask . . . . . . . . . . . . . : 255.255.255.0
 Gateway predefinito . . . . . . . . . :

Scheda Ethernet VMware Network Adapter VMnet1:

 Suffisso DNS specifico per connessione:
 Indirizzo IP. . . . . . . . . . . . . : 192.168.153.1
 Subnet mask . . . . . . . . . . . . . : 255.255.255.0
 Gateway predefinito . . . . . . . . . :

Scheda Ethernet Connessione rete senza fili:

 Stato supporto . . . . . . . . . . . : Supporto disconnesso

Scheda Ethernet Connessione alla rete locale (LAN):

 Suffisso DNS specifico per connessione:
 Indirizzo IP. . . . . . . . . . . . . : 192.168.0.75
 Subnet mask . . . . . . . . . . . . . : 255.255.255.0
 Gateway predefinito . . . . . . . . . : 192.168.0.10

Scheda Ethernet Connessione alla rete locale (LAN) 3:

 Stato supporto . . . . . . . . . . . : Supporto disconnesso

Vediamo di leggere e capire questo risultato. Il mio portatile sembra avere 5 schede di rete di cui una, senza fili (riga 16) che però non risulta collegata, due LAN (riga 20 e 27) di cui una non collegata e due “strane” (riga 2 e 9). Tralasciando quest’ultime due, che per inciso, sono due schede virtuali del software VMWare, e tralasciando l’ultima disconnessa che è, in realtà, essa stessa una scheda virtuale di un software di VPN, rimane quella in riga 20 che risulta connessa. Dato che ho lanciato questo comando con il portatile collegato con il cavo alla rete va da se che la scheda di rete relativa è proprio questa.

La scheda giusta, in una situazione “regolare” si riconosce anche perchè è l’unica ad avere il gateway predefinito ossia l’indirizzo IP del nostro router.

Focalizzandoci su questa sola scheda di rete, se il cavo di rete non risulta collegato correttamente, se il cavo è rotto, se la scheda di rete è rotta, se dall’altra parte del filo, l’apparato è spento, il risultato sarà ovviamente

Scheda Ethernet Connessione alla rete locale (LAN):

 Stato supporto . . . . . . . . . . . : Supporto disconnesso

Se la vostra scheda di rete si presenta cosi, dovete quindi andare a cercare un problema fisico sulla rete dovuto alla vostra o alla scheda di rete dall’altro capo del filo o un problema sul filo. Nel caso in cui invece il vostro collegamento fosse wireless allora dovete verificare che l’access point o il vostro router wireless sia acceso e funzionante e che i parametri di accesso alla rete wireless (cifratura, chiave) siano corretti.

Un caso particolare non corretto è questo qui sotto

Scheda Ethernet Connessione alla rete locale (LAN):

 Suffisso DNS specifico per connessione:
 Indirizzo IP configurazione automatica: 169.254.175.118
 Subnet mask . . . . . . . . . . . . . : 255.255.0.0
 Gateway predefinito . . . . . . . . . :

che evidenzia un problema particolare della vostra rete. Se la vostra rete vi assegna un indirizzo IP della serie 169.x.x.x allora la scheda di rete che è ovviamente collegata alla vostra rete, si aspettava che la vostra rete gli assegnasse un indirizzo IP ma questa cosa non è avvunuta e quindi lei si è messa un indirizzo IP “di emergenza” ma che, per quello che vi riguarda non serve sostanzialmente a nulla.

In sostanza, sulla vostra rete non vi è in questo momento un server DHCP che possa fornire gli IP al vostro computer. I casi sono due. O per utilizzare la rete è necessario fornire una configurazione manuale di indirizzo IP, netmask e gateway o, appunto, il server DHCP, che di solito si trova nel vostro router è spento, non raggiungibile o non configurato.

Come prima cosa proverei a verificare se il router è acceso, funzionante e collegato alla rete.

Test 3 – Ping del gateway

La terza prova da fare è quella di fare il ping al vostro router ossia all’indirizzo IP del gateway ottenuto dal comando ipconfig dato nel test precedente, ossia, nel mio caso, 192.168.0.10

Lanciando quindi il comando

ping 192.168.0.10

si deve ottenere qualcosa del genere:

ping 192.168.0.10

Pinging 192.168.0.10 with 32 bytes of data:
Reply from 192.168.0.10: bytes=32 time 1ms TTL=128
Reply from 192.168.0.10: bytes=32 time 2ms TTL=128
Reply from 192.168.0.10: bytes=32 time 1ms TTL=128
Reply from 192.168.0.10: bytes=32 time 2ms TTL=128

Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 2ms, Average = 1ms

Questo significa che, non solo la vostra rete locale è funzionante ma che il vostro router è acceso, funzionante e raggiungibile.

Se invece questo test fallisce allora c’è qualche problema nel raggiungere il vostro router che può essere spento, impallato, con il cavo di rete staccato e comunque irraggiungibile. Focalizzatevi quindi nel capire come mai il vostro router non si raggiunge.

Un ulteriore tentativo, se si ha un altro PC collegato alla rete e provare a capire se si raggiunge l’altro PC pingandolo. Se non si raggiunge il problema è generalizzato sulla vostra rete o forse il problema è solo sul vostro PC. Se lo si raggiunge, il problema è esclusivamente sul vostro router.

Test 4 – Ping IP esterno (8.8.8.8 o 151.1.1.1)

Se il vostro router è raggiungibile, è giunto il momento di testare la vostra connessione INTERNET. Per fare questo, il modo più veloce è quello di pingare alcuni host esterni. Io, a livello mnemonico provo a pingare o l’8.8.8.8 ossia il DNS principale di Google o 151.1.1.1, il DNS principale di IT.NET

Come sopra, ambedue questi ping devono riuscire. Se non riescono allora il problema è che la vostra connettività. Contattate il vostro ISP.

Text 5 – Ping FQDN (www.iol.it)

A questo punto, anche se c’è qualcosa che non va, comunque siamo collegati su INTERNET visto che i ping, ad indirizzi numerici, funzionano.

L’ultimo step è cercare di pingare un FQDN, tipo www.iol.it

Se questo host fallisce allora il problema è sul vostro DNS. Provate a mettere sul PC quello di Google (8.8.8.8) o controllato comunque le impostazioni di DNS.

Se invece anche questo test ha successo allora il problema può risiedere in una impostazione di proxy o un problema di virus.

Questo articolo è stato visto 317 volta

2 Responses to “Perchè la mia ADSL non funziona”

  • massimo scrive:

    bel post, sarebbe carino automatizzare il check con un tool … :-)

    Rispondi

    Emiliano Bruni Reply:

    Si, si pensava a fare proprio questo un po’ di tempo fa ma non c’è stato mai tempo per svilupparlo.

    Rispondi

Lascia un commento

 

Categorie

  • abruzzo (3)
  • America's Army (6)
  • Android (1)
  • Controguerra (54)
  • Croce Verde (23)
  • devTv.eu (6)
  • eventi (46)
  • Fisica (8)
  • Giochi (7)
  • howto (5)
  • Humor (102)
  • internet (20)
  • Iphone (17)
  • linux (8)
  • Linux Pro (3)
  • Medicina (25)
  • Micso (61)
  • Modding (19)
  • musica (4)
  • News (22)
  • politica (7)
  • programmazione (9)
  • Quale parte di… (4)
  • Radioamatore (1)
  • Rassegna stampa (5)
  • Recenzioni (34)
  • RFID (1)
  • Riflessioni (45)
  • sport (42)
  • tecnologia (15)
  • Telug (2)
  • Video (81)
  • Vita vissuta (56)
  • Web (34)
  • Windows (12)
  • ping 127.0.0.1

    si deve ottenere qualcosa del genere:

    ping 127.0.0.1
    
    Pinging 127.0.0.1 with 32 bytes of data:
    Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
    Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
    Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
    Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
    
    Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

    Questo è il risultato corretto da ottenere che, a parte i valori in millisecondi di risposta, indica comunque che l’interfaccia di loopback è funzionante e risponde.

    Una risposta diversa, in particolare un messaggio di errore hardware o comunque una mancata risposta al ping sta ad indicare che: o lo stack TCP/IP non è configurato o non è abilitato o che, qualcosa, un virus o un settore del disco difettoso, ha corrotto le librerie che stanno alla base del funzionamento di questo protocollo sul vostro PC.

    Test 2 – La rete è connessa?

    La seconda verifica è controllare se siamo collegati ad una rete e se abbiamo un indirizzo IP “giusto”.

    Per fare questo utilizziamo un altro comando del “prompt” chiamato ipconfig. Questo comando ci da informazioni su tutte le schede di rete su cui è abilitato il TCP/IP.

    In particolare dovremo vedere se la scheda di rete “principale” o quella wireless è collegata e ha un indirizzo IP “giusto”.

    Per questo vi serve un po’ di abilità nel riconoscere la scheda di rete giusta. Vediamo un esempio del comando ipconfig sul mio portatile. Il risultato del comando è

    Configurazione IP di Windows
    Scheda Ethernet VMware Network Adapter VMnet8:
    
     Suffisso DNS specifico per connessione:
     Indirizzo IP. . . . . . . . . . . . . : 192.168.49.1
     Subnet mask . . . . . . . . . . . . . : 255.255.255.0
     Gateway predefinito . . . . . . . . . :
    
    Scheda Ethernet VMware Network Adapter VMnet1:
    
     Suffisso DNS specifico per connessione:
     Indirizzo IP. . . . . . . . . . . . . : 192.168.153.1
     Subnet mask . . . . . . . . . . . . . : 255.255.255.0
     Gateway predefinito . . . . . . . . . :
    
    Scheda Ethernet Connessione rete senza fili:
    
     Stato supporto . . . . . . . . . . . : Supporto disconnesso
    
    Scheda Ethernet Connessione alla rete locale (LAN):
    
     Suffisso DNS specifico per connessione:
     Indirizzo IP. . . . . . . . . . . . . : 192.168.0.75
     Subnet mask . . . . . . . . . . . . . : 255.255.255.0
     Gateway predefinito . . . . . . . . . : 192.168.0.10
    
    Scheda Ethernet Connessione alla rete locale (LAN) 3:
    
     Stato supporto . . . . . . . . . . . : Supporto disconnesso

    Vediamo di leggere e capire questo risultato. Il mio portatile sembra avere 5 schede di rete di cui una, senza fili (riga 16) che però non risulta collegata, due LAN (riga 20 e 27) di cui una non collegata e due “strane” (riga 2 e 9). Tralasciando quest’ultime due, che per inciso, sono due schede virtuali del software VMWare, e tralasciando l’ultima disconnessa che è, in realtà, essa stessa una scheda virtuale di un software di VPN, rimane quella in riga 20 che risulta connessa. Dato che ho lanciato questo comando con il portatile collegato con il cavo alla rete va da se che la scheda di rete relativa è proprio questa.

    La scheda giusta, in una situazione “regolare” si riconosce anche perchè è l’unica ad avere il gateway predefinito ossia l’indirizzo IP del nostro router.

    Focalizzandoci su questa sola scheda di rete, se il cavo di rete non risulta collegato correttamente, se il cavo è rotto, se la scheda di rete è rotta, se dall’altra parte del filo, l’apparato è spento, il risultato sarà ovviamente

    Scheda Ethernet Connessione alla rete locale (LAN):
    
     Stato supporto . . . . . . . . . . . : Supporto disconnesso

    Se la vostra scheda di rete si presenta cosi, dovete quindi andare a cercare un problema fisico sulla rete dovuto alla vostra o alla scheda di rete dall’altro capo del filo o un problema sul filo. Nel caso in cui invece il vostro collegamento fosse wireless allora dovete verificare che l’access point o il vostro router wireless sia acceso e funzionante e che i parametri di accesso alla rete wireless (cifratura, chiave) siano corretti.

    Un caso particolare non corretto è questo qui sotto

    Scheda Ethernet Connessione alla rete locale (LAN):
    
     Suffisso DNS specifico per connessione:
     Indirizzo IP configurazione automatica: 169.254.175.118
     Subnet mask . . . . . . . . . . . . . : 255.255.0.0
     Gateway predefinito . . . . . . . . . :

    che evidenzia un problema particolare della vostra rete. Se la vostra rete vi assegna un indirizzo IP della serie 169.x.x.x allora la scheda di rete che è ovviamente collegata alla vostra rete, si aspettava che la vostra rete gli assegnasse un indirizzo IP ma questa cosa non è avvunuta e quindi lei si è messa un indirizzo IP “di emergenza” ma che, per quello che vi riguarda non serve sostanzialmente a nulla.

    In sostanza, sulla vostra rete non vi è in questo momento un server DHCP che possa fornire gli IP al vostro computer. I casi sono due. O per utilizzare la rete è necessario fornire una configurazione manuale di indirizzo IP, netmask e gateway o, appunto, il server DHCP, che di solito si trova nel vostro router è spento, non raggiungibile o non configurato.

    Come prima cosa proverei a verificare se il router è acceso, funzionante e collegato alla rete.

    Test 3 – Ping del gateway

    La terza prova da fare è quella di fare il ping al vostro router ossia all’indirizzo IP del gateway ottenuto dal comando ipconfig dato nel test precedente, ossia, nel mio caso, 192.168.0.10

    Lanciando quindi il comando

    ping 192.168.0.10

    si deve ottenere qualcosa del genere:

    ping 192.168.0.10
    
    Pinging 192.168.0.10 with 32 bytes of data:
    Reply from 192.168.0.10: bytes=32 time 1ms TTL=128
    Reply from 192.168.0.10: bytes=32 time 2ms TTL=128
    Reply from 192.168.0.10: bytes=32 time 1ms TTL=128
    Reply from 192.168.0.10: bytes=32 time 2ms TTL=128
    
    Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 2ms, Average = 1ms

    Questo significa che, non solo la vostra rete locale è funzionante ma che il vostro router è acceso, funzionante e raggiungibile.

    Se invece questo test fallisce allora c’è qualche problema nel raggiungere il vostro router che può essere spento, impallato, con il cavo di rete staccato e comunque irraggiungibile. Focalizzatevi quindi nel capire come mai il vostro router non si raggiunge.

    Un ulteriore tentativo, se si ha un altro PC collegato alla rete e provare a capire se si raggiunge l’altro PC pingandolo. Se non si raggiunge il problema è generalizzato sulla vostra rete o forse il problema è solo sul vostro PC. Se lo si raggiunge, il problema è esclusivamente sul vostro router.

    Test 4 – Ping IP esterno (8.8.8.8 o 151.1.1.1)

    Se il vostro router è raggiungibile, è giunto il momento di testare la vostra connessione INTERNET. Per fare questo, il modo più veloce è quello di pingare alcuni host esterni. Io, a livello mnemonico provo a pingare o l’8.8.8.8 ossia il DNS principale di Google o 151.1.1.1, il DNS principale di IT.NET

    Come sopra, ambedue questi ping devono riuscire. Se non riescono allora il problema è che la vostra connettività. Contattate il vostro ISP.

    Text 5 – Ping FQDN (www.iol.it)

    A questo punto, anche se c’è qualcosa che non va, comunque siamo collegati su INTERNET visto che i ping, ad indirizzi numerici, funzionano.

    L’ultimo step è cercare di pingare un FQDN, tipo www.iol.it

    Se questo host fallisce allora il problema è sul vostro DNS. Provate a mettere sul PC quello di Google (8.8.8.8) o controllato comunque le impostazioni di DNS.

    Se invece anche questo test ha successo allora il problema può risiedere in una impostazione di proxy o un problema di virus.

Questo articolo è stato visto 317 volta

2 Responses to “Perchè la mia ADSL non funziona”

  • massimo scrive:

    bel post, sarebbe carino automatizzare il check con un tool … :-)

    Rispondi

    Emiliano Bruni Reply:

    Si, si pensava a fare proprio questo un po’ di tempo fa ma non c’è stato mai tempo per svilupparlo.

    Rispondi

Lascia un commento

 

Categorie