Problema di connessione intrigante su OS X

33

Recentemente ho riscontrato questo problema con la mia connessione Internet sul mio MacBook Pro agli inizi del 2011 su OS X 10.8.3: di tanto in tanto la connessione "si blocca" per circa 5 secondi e poi torna indietro.

Accade sia tramite Wi-Fi che tramite cavo Ethernet e succede solo alla mia macchina quando è in esecuzione OS X (non si verifica quando si esegue Windows 7 sullo stesso computer o su qualsiasi altra macchina / dispositivo). Fa cadere le chiamate su Skype ogni 2 minuti o giù di lì, quindi è molto frustrante.

Il ping di Google.com si presenta così quando si esegue OS X (ci sono centinaia di pacchetti che ritornano in meno di 100 ms (con alcuni nell'intervallo 130), quindi una interruzione per diversi secondi) :

64 bytes from 173.194.34.196: icmp_seq=694 ttl=48 time=71.463 ms
64 bytes from 173.194.34.196: icmp_seq=695 ttl=48 time=68.362 ms
64 bytes from 173.194.34.196: icmp_seq=696 ttl=48 time=69.056 ms
64 bytes from 173.194.34.196: icmp_seq=697 ttl=48 time=92.563 ms
64 bytes from 173.194.34.196: icmp_seq=698 ttl=48 time=130.814 ms
64 bytes from 173.194.34.196: icmp_seq=699 ttl=48 time=71.054 ms
64 bytes from 173.194.34.196: icmp_seq=700 ttl=48 time=73.588 ms
64 bytes from 173.194.34.196: icmp_seq=701 ttl=48 time=71.185 ms
64 bytes from 173.194.34.196: icmp_seq=702 ttl=48 time=72.161 ms
64 bytes from 173.194.34.196: icmp_seq=703 ttl=48 time=69.163 ms
64 bytes from 173.194.34.196: icmp_seq=704 ttl=48 time=73.425 ms
64 bytes from 173.194.34.196: icmp_seq=705 ttl=48 time=141.980 ms
64 bytes from 173.194.34.196: icmp_seq=706 ttl=48 time=226.818 ms
64 bytes from 173.194.34.196: icmp_seq=707 ttl=48 time=210.087 ms
Request timeout for icmp_seq 708
Request timeout for icmp_seq 709
Request timeout for icmp_seq 710
Request timeout for icmp_seq 711
Request timeout for icmp_seq 712
64 bytes from 173.194.34.196: icmp_seq=713 ttl=48 time=73.582 ms
64 bytes from 173.194.34.196: icmp_seq=714 ttl=48 time=70.994 ms
64 bytes from 173.194.34.196: icmp_seq=715 ttl=48 time=72.502 ms
64 bytes from 173.194.34.196: icmp_seq=716 ttl=48 time=70.467 ms
64 bytes from 173.194.34.196: icmp_seq=717 ttl=48 time=68.470 ms
64 bytes from 173.194.34.196: icmp_seq=718 ttl=48 time=70.767 ms
64 bytes from 173.194.34.196: icmp_seq=719 ttl=48 time=69.078 ms

Nota: il MAC Wi-Fi della mia macchina è 68: a8: 6d: 29: cf: 8a (IP statico 192.168.1.250) e il suo indirizzo Ethernet è 3c: 07: 54: 5a: e0: 44 (IP statico 192.168 .1.251). L'IP LAN del router è 192.168.1.1 e il suo IP WAN è 85.61.155.224.

Nel prossimo screenshot si può vedere, durante una chiamata Skype:

  • ping 192.168.1.1 in alto a sinistra.
  • ping 85.61.155.224 in basso a sinistra.
  • ping google.com in basso a destra.
  • i comandi arp -an e arp -ad eseguiti.

Quando ho eseguito il comando arp -ad in un momento in cui la connessione è stata persa, l'elenco non mostrava alcun indirizzo. Sembrava questo:

Miguels-MacBook-Pro:~ Ai$ sudo arp -ad
192.168.1.1 (192.168.1.1) deleted
192.168.1.4 (192.168.1.4) deleted
192.168.1.255 (192.168.1.255) deleted
Miguels-MacBook-Pro:~ Ai$ arp -an
Miguels-MacBook-Pro:~ Ai$

Non ho conoscenze sufficienti per seguire le istruzioni di mike su come ottenere e compilare l'origine del comando mtr .

Eccocomestannolecosequandoèpeggio:

L'esecuzione di netstat -s restituisce:

Miguels-MacBook-Pro:mtr-0.84 Ai$ NETSTAT -s
tcp:
    18246745 packets sent
        1119644 data packets (502840461 bytes)
        43704 data packets (23125605 bytes) retransmitted
        1 resend initiated by MTU discovery
        11219994 ack-only packets (80633 delayed)
        0 URG only packets
        10 window probe packets
        5446529 window update packets
        419140 control packets
        0 data packets sent after flow control
    25777361 packets received
        1284807 acks (for 502390806 bytes)
        222223 duplicate acks
        2 acks for unsent data
        21993647 packets (3385435972 bytes) received in-sequence
        85441 completely duplicate packets (85927570 bytes)
        189 old duplicate packets
        6141 packets with some dup. data (1633845 bytes duped)
        2225930 out-of-order packets (3047304289 bytes)
        2 packets (0 bytes) of data after window
        0 window probes
        7324 window update packets
        63837 packets received after close
        56 bad resets
        9 discarded for bad checksums
        0 discarded for bad header offset fields
        0 discarded because packet too short
    200907 connection requests
    118631 connection accepts
    110736 bad connection attempts
    1273 listen queue overflows
    220132 connections established (including accepts)
    335687 connections closed (including 10893 drops)
        4086 connections updated cached RTT on close
        4086 connections updated cached RTT variance on close
        1485 connections updated cached ssthresh on close
    44620 embryonic connections dropped
    1178835 segments updated rtt (of 1308648 attempts)
    76481 retransmit timeouts
        189 connections dropped by rexmit timeout
        0 connections dropped after retransmitting FIN
    17 persist timeouts
        0 connections dropped by persist timeout
    2015 keepalive timeouts
        1 keepalive probe sent
        1409 connections dropped by keepalive
    127007 correct ACK header predictions
    21519356 correct data packet header predictions
    5021 SACK recovery episodes
    5638 segment rexmits in SACK recovery episodes
    6044752 byte rexmits in SACK recovery episodes
    33658 SACK options (SACK blocks) received
    2125185 SACK options (SACK blocks) sent
    0 SACK scoreboard overflow
udp:
    28584263 datagrams received
    0 with incomplete header
    0 with bad data length field
    84 with bad checksum
    4216 dropped due to no socket
    239052 broadcast/multicast datagrams dropped due to no socket
    729188 dropped due to full socket buffers
    0 not for hashed pcb
    27611723 delivered
    28323341 datagrams output
ip:
    61548853 total packets received
    4 bad header checksums
    0 with size smaller than minimum
    0 with data size < data length
    0 with ip length > max ip packet size
    0 with header length < data size
    0 with data length < header length
    0 with bad options
    0 with incorrect version number
    103276 fragments received
    0 fragments dropped (dup or out of space)
    0 fragments dropped after timeout
    51420 packets reassembled ok
    61383903 packets for this host
    32 packets for unknown/unsupported protocol
    0 packets forwarded (0 packets fast forwarded)
    105 packets not forwardable
    112953 packets received for unknown multicast group
    0 redirects sent
    53953058 packets sent from this host
    155 packets sent with fabricated ip header
    0 output packets dropped due to no bufs, etc.
    3748 output packets discarded due to no route
    0 output datagrams fragmented
    0 fragments created
    0 datagrams that can't be fragmented
    0 tunneling packets that can't find gif
    3 datagrams with bad address in header
    0 packets dropped due to no bufs for control data
icmp:
    4216 calls to icmp_error
    0 errors not generated 'cuz old message was icmp
    Output histogram:
        echo reply: 202
        destination unreachable: 4216
    0 messages with bad code fields
    0 messages < minimum length
    168 bad checksums
    0 messages with bad length
    0 multicast echo requests ignored
    0 multicast timestamp requests ignored
    Input histogram:
        echo reply: 7013069
        destination unreachable: 14133
        echo: 202
        time exceeded: 289
    202 message responses generated
    ICMP address mask responses are disabled
igmp:
    0 messages received
    0 messages received with too few bytes
    0 messages received with wrong TTL
    0 messages received with bad checksum
    0 V1/V2 membership queries received
    0 V3 membership queries received
    0 membership queries received with invalid field(s)
    0 general queries received
    0 group queries received
    0 group-source queries received
    0 group-source queries dropped
    0 membership reports received
    0 membership reports received with invalid field(s)
    0 membership reports received for groups to which we belong
    0 V3 reports received without Router Alert
    16 membership reports sent
ipsec:
    0 inbound packets processed successfully
    0 inbound packets violated process security policy
    0 inbound packets with no SA available
    0 invalid inbound packets
    0 inbound packets failed due to insufficient memory
    0 inbound packets failed getting SPI
    0 inbound packets failed on AH replay check
    0 inbound packets failed on ESP replay check
    0 inbound packets considered authentic
    0 inbound packets failed on authentication
    0 outbound packets processed successfully
    0 outbound packets violated process security policy
    0 outbound packets with no SA available
    0 invalid outbound packets
    0 outbound packets failed due to insufficient memory
    0 outbound packets with no route
ip6:
    151513 total packets received
    0 with size smaller than minimum
    0 with data size < data length
    0 with bad options
    0 with incorrect version number
    0 fragments received
    0 fragments dropped (dup or out of space)
    0 fragments dropped after timeout
    0 fragments that exceeded limit
    0 packets reassembled ok
    5555 packets for this host
    0 packets forwarded
    145711 packets not forwardable
    0 redirects sent
    2608 packets sent from this host
    0 packets sent with fabricated ip header
    0 output packets dropped due to no bufs, etc.
    4578 output packets discarded due to no route
    23 output datagrams fragmented
    46 fragments created
    0 datagrams that can't be fragmented
    0 packets that violated scope rules
    145711 multicast packets which we don't join
    Input histogram:
        hop by hop: 2327
        TCP: 244
        UDP: 142524
        ICMP6: 6416
    Mbuf statistics:
        244 one mbuf
        two or more mbuf:
            lo0= 2215
        149054 one ext mbuf
        0 two or more ext mbuf
    0 packets whose headers are not continuous
    0 tunneling packets that can't find gif
    0 packets discarded due to too may headers
    0 failures of source address selection
    0 forward cache hit
    0 forward cache miss
    0 packets dropped due to no bufs for control data
icmp6:
    0 calls to icmp_error
    0 errors not generated because old message was icmp error or so
    0 errors not generated because rate limitation
    Output histogram:
        router solicitation: 50
        neighbor solicitation: 19
        neighbor advertisement: 19
        MLDv2 listener report: 59
    0 messages with bad code fields
    0 messages < minimum length
    0 bad checksums
    0 messages with bad length
    Input histogram:
        neighbor advertisement: 245
    Histogram of error messages to be generated:
        0 no route
        0 administratively prohibited
        0 beyond scope
        0 address unreachable
        0 port unreachable
        0 packet too big
        0 time exceed transit
        0 time exceed reassembly
        0 erroneous header field
        0 unrecognized next header
        0 unrecognized option
        0 redirect
        0 unknown
    0 message responses generated
    0 messages with too many ND options
    0 messages with bad ND options
    0 bad neighbor solicitation messages
    0 bad neighbor advertisement messages
    0 bad router solicitation messages
    0 bad router advertisement messages
    0 bad redirect messages
    0 path MTU changes
ipsec6:
    0 inbound packets processed successfully
    0 inbound packets violated process security policy
    0 inbound packets with no SA available
    0 invalid inbound packets
    0 inbound packets failed due to insufficient memory
    0 inbound packets failed getting SPI
    0 inbound packets failed on AH replay check
    0 inbound packets failed on ESP replay check
    0 inbound packets considered authentic
    0 inbound packets failed on authentication
    0 outbound packets processed successfully
    0 outbound packets violated process security policy
    0 outbound packets with no SA available
    0 invalid outbound packets
    0 outbound packets failed due to insufficient memory
    0 outbound packets with no route
rip6:
    0 messages received
    0 checksum calcurations on inbound
    0 messages with bad checksum
    0 messages dropped due to no socket
    0 multicast messages dropped due to no socket
    0 messages dropped due to full socket buffers
    0 delivered
    0 datagrams output
pfkey:
    0 requests sent to userland
    0 bytes sent to userland
    0 messages with invalid length field
    0 messages with invalid version field
    0 messages with invalid message type field
    0 messages too short
    0 messages with memory allocation failure
    0 messages with duplicate extension
    0 messages with invalid extension type
    0 messages with invalid sa type
    0 messages with invalid address extension
    0 requests sent from userland
    0 bytes sent from userland
    0 messages toward single socket
    0 messages toward all sockets
    0 messages toward registered sockets
    0 messages with memory allocation failure

L'esecuzione di netstat -I en1 restituisce:

Miguels-MacBook-Pro-2:mtr-0.84 Ai$ netstat -I en1
Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
en1   1500  <Link#5>    68:a8:6d:29:cf:8a 72539835     0 63847581     0     0
en1   1500  fe80::6aa8: fe80:5::6aa8:6dff 72539835     - 63847581     -     -
en1   1500  192.168.1     192.168.1.250   72539835     - 63847581     -     -

L'esecuzione di ifconfig -a restituisce:

Miguels-MacBook-Pro-2:mtr-0.84 Ai$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
    ether 3c:07:54:5a:e0:44 
    media: autoselect (none)
    status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 68:a8:6d:29:cf:8a 
    inet6 fe80::6aa8:6dff:fe29:cf8a%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.1.250 netmask 0xffffff00 broadcast 192.168.1.255
    media: autoselect
    status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
    ether 0a:a8:6d:29:cf:8a 
    media: autoselect
    status: inactive
fw0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 4078
    lladdr a4:b1:97:ff:fe:ec:f0:80 
    media: autoselect <full-duplex>
    status: inactive

Cosa penso:

  • Non si tratta di un problema relativo al Wi-Fi perché avviene anche via cavo.
  • Non si tratta di un problema router / ISP perché altri dispositivi e macchine non hanno alcun problema.
  • Non è un problema di macchina perché accade solo quando si esegue OS X.
  • Deve quindi essere un problema di OS X.

Quello che ho provato:

  • Riavvia, arresta.
  • Attiva e disattiva AirPort, diversi cavi Ethernet.
  • Autorizzazioni di riparazione.
  • Reimposta la PRAM.
  • Cancella tutte le cache di sistema e utente con Onyx.

Nota strana: Per qualche strana ragione il problema sembra peggiorare quando si sta verificando una chiamata skype.

Gradirei apprezzare le idee su come affrontare questo problema.

    
posta Mike D. 26.04.2013 - 17:28
fonte

17 risposte

13

Quando le connessioni iniziano a scadere, puoi fare arp -an in Terminal.app e vedere se hai ancora tutti gli indirizzi MAC nella tabella ARP? come in - l'indirizzo MAC del tuo router o l'host che stai tentando di eseguire il ping?

Se lo fai (e hai tempo prima che riprenda a funzionare), puoi svuotare la tabella arp ( sudo arp -ad ) e poi vedere se l'indirizzo MAC del tuo router appare di nuovo nella tabella ARP?

Inoltre, prova a eseguire un ping sull'indirizzo IP LAN del tuo router in una sessione di Terminale e magari a eseguire un ping all'indirizzo IP WAN del tuo router in un altro mentre sei su Skype. Vedi se tutti iniziano a scadere o solo uno di loro. Un altro strumento che trovo utile è mtr - potrebbe essere necessario procurarsi il codice sorgente e compilarlo da soli o utilizzare fink / macports o un altro gestore di pacchetti. Quando lo ottieni, eseguilo su una destinazione da qualche parte su Internet e ti mostrerà quale hop smette di rispondere.

Come installare il software da sorgenti (come mtr) Richiede Xcode da installare :

  • scarica l'archivio sorgente (in genere .tar.gz o .tar.bz2)
  • decomprimere il file scaricato (ad esempio in Terminal.app esegui gzip -dc filename.tar.gz | tar -xvf - , che in genere creerà una nuova directory nella directory corrente e inserirà il contenuto dell'archivio)
  • vai alla cartella ottenuta nel terminale
  • Esegui ./configure --prefix=/usr/local (tieni presente che mi piace installare il software dal sorgente in /usr/local per tenerlo lontano dai binari installati come parte del sistema, l'opzione --prefix=/usr/local da configurare farà proprio questo)
  • Esegui make
  • Esegui sudo make install
  • fatto!
risposta data 02.05.2013 - 00:46
fonte
6

Potresti prima controllare che stai usando veramente l'interfaccia di rete dovresti:

ifconfig -a

Potresti vedere l'output dei seguenti comandi (se en0 è il nome dell'interfaccia di rete della scheda Ethernet):

netstat -I en0

Per aiutare a localizzare il problema potresti creare una Location specifica con Just la tua scheda Ethernet è attivata e, se possibile, utilizza solo IPv4 o IPv6 ma non entrambi:

Puoi eseguire il seguente estratto di potenziali errori hardware o del driver:

grep ' en[012]' /var/log/kernel.log

(non spaventarti potresti trovare molte informazioni sui canali Wi-Fi).

Il seguente messaggio mostrato dal tuo netstat:

44620 embryonic connections dropped

significa che sei in realtà il bersaglio di un sciocco tcp syn flooding (che è un attacco denial of service (DOS).

Quando il tuo:

ping 192.168.1.1

soffoca per 6 secondi, potresti eseguire:

netstat -m
    
risposta data 08.05.2013 - 19:58
fonte
4

Ho avuto questo problema da molto tempo (iniziando dopo un aggiornamento a Mavericks) e, dopo mesi di ricerche, penso di aver finalmente trovato una soluzione.

Prima di tutto, ci sono un certo numero di persone con lo stesso problema nei forum Apple:

Quindi questo è un problema noto e non so davvero perché Apple non abbia ancora fornito una soluzione per questo. Nei thread sopra elencati, ci sono molti suggerimenti per risolvere questo problema, ma la maggior parte di quelli non ha funzionato. Alcuni risolvono il problema temporaneamente:

  • Disconnetti e riconnetti la rete
  • Il vecchio amico: riavvia
  • Rimuovi la cartella contenente la configurazione di rete: sudo rm -rf /Library/Preferences/SystemConfiguration

Dopo queste misure, la connessione di rete si sente molto meglio e non subisco perdite per diverse ore o talvolta anche giorni. Ma i problemi tornano sempre.

Questa domanda e gli indizi che il problema potrebbe essere correlato all'ARP mi hanno portato a iniziare ulteriori ricerche e ho trovato questa pagina , che descrive il bug in dettaglio e contiene anche una patch, che cito qui:

sudo su
touch /etc/sysctl.conf
echo net.link.ether.inet.arp_unicast_lim=0 >> /etc/sysctl.conf
chown root:wheel /etc/sysctl.conf
chmod 0644 /etc/sysctl.conf

Fai riferimento al link fornito per una spiegazione approfondita della correzione, che dovrebbe essere inclusa in un futuro aggiornamento del sistema operativo per Yosemite di Apple. Disabilita le richieste ARP unicast, che causano confusione con alcune apparecchiature di rete come il router di casa.

Dopo aver applicato la correzione e il riavvio, dovrebbe essere controllato se

sudo sysctl -a | grep net.link.ether.inet.arp_unicast_lim

restituisce net.link.ether.inet.arp_unicast_lim: 0 . Se il numero non è uguale a zero, la correzione non è stata applicata correttamente.

In seguito, ho trovato un altro thread nelle community di apple che contiene la stessa soluzione: Mavericks e ARP non riusciti che causano il calo della rete ! Bene, dopo aver saputo qual è il problema, trovare la soluzione corretta è molto più semplice.

    
risposta data 09.12.2014 - 13:15
fonte
3

In primo luogo, vedo dropbox in esecuzione nella barra dei menu; hai disabilitato quello, ancora?

In secondo luogo, prova a rimuovere qualsiasi altro elemento di avvio / login. Guarda in:

Login:

  1. ~ / Library / LaunchAgents /
  2. ~ / Library / LaunchDaemons /
  3. Preferenze di sistema > Utenti e amp; Gruppi > Elementi di login

Avvio:

  1. / Library / LaunchAgents /
  2. / Library / LaunchDaemons /
  3. / Library / StartupItems /
  4. /Library/Preferences/com.apple.loginitems.plist (raramente esiste)
risposta data 05.05.2013 - 18:00
fonte
2

Qui ci sono molte informazioni sulla risoluzione dei problemi e sulla diagnostica, ma a volte durante la risoluzione dei problemi è divertente tornare alle origini e mettere in discussione alcune ipotesi.

Come ho accennato in un commento, sembra molto simile a un router QOS che si attiva a causa del fatto che la tua macchina temporaneamente supera la larghezza di banda o il limite di velocità del pacchetto.

Che cosa succede se stai facendo diversi pattern, volumi e quantità di traffico di rete su OS X rispetto a Windows e questa è la vera causa, non i driver hardware o il software?

Mi aspetto che l'esecuzione di OS X sia correlata con le tue osservazioni, ma cosa succede se non è la causa delle pause temporanee della rete.

Hai provato a cercare cosa fare se i filtri QOS e le modifiche al routing sono implementati dal tuo gestore di rete? Avete considerato di effettuare il tunneling di tutto il traffico su un altro computer (ssh o VPN) in modo da poter escludere filtri banali. (Se il provider sta eseguendo un'ispezione approfondita dei pacchetti, oppure una destinazione e una limitazione della velocità effettiva - potresti non essere in grado di evitare questi brevi timeout.)

Spero che ci sia una risposta che puoi trovare guardando i dettagli della rete (e impareremo tutti qualcosa dall'esplorare quelle opzioni) - ma assicurati anche di considerare che i tuoi strumenti di misurazione e il traffico aggiunto a ping / poke a cose potrebbe influenzare il conteggio del traffico e rendendo più probabile che Skype cadrà per voi. I router che ho configurato sono programmati per eliminare il traffico ICMP prima di tutto il traffico da quando la capacità si riduce - preferisco il ping fallire e altri pacchetti passano attraverso. L'ISP e il provider di rete potrebbero aver impostato le cose in modo simile.

    
risposta data 09.05.2013 - 20:21
fonte
2

Oltre a tutto ciò qui, è necessario assicurarsi che Auto Discovery Proxy non sia attivo (così come Configurazione proxy automatica). Questo tende a causare più problemi e non è spesso necessario.

    
risposta data 09.05.2013 - 22:29
fonte
2

Con tutte le grandi informazioni diagnostiche in questa domanda hai ristretto notevolmente le possibilità.

Per cominciare, i ping a 192.168.1.1 isolano notevolmente il problema sul router, sul computer o sulla LAN. Questo non è un problema con DNS o ISP.

Sono molto disturbato dai risultati dei test di ping su 192.168.1.1. Hai fatto qualcosa di strano nel configurarli?

Ad esempio, si hanno ping riusciti con numeri di sequenza ICMP di 24267, 24268 e 24269, quindi 3 timeout, quindi si ripete nuovamente con ICMP 24273. Quindi i numeri dei successi sembrano giusti. Tuttavia, i numeri dei timeout sono completamente diversi. Mi aspetterei di vedere i timeout delle richieste da ICMP 24270, 24271 e 24272 ma invece i timeout riportano ICMP 89806, 89807 e 89808. Non l'ho mai visto prima e quindi per me suggerisce di avere uno stack di rete rotto su quello computer. Forse troppe estensioni. Qualche possibilità che hai installato Netgear Genie? O forse il software VPN?

In ogni caso, direi che è ora di iniziare a disattivare i "miglioramenti" per vedere se riesci a trovare un colpevole installato sul computer.

Modifica

OK, mistero risolto. Il numero di sequenza ICMP è un campo a 16 bit. Trattata come un numero intero senza segno, significa che ha un valore massimo di 65.535 e quindi si avvolge attorno allo zero. Quindi, se il programma ping locale sta mantenendo un contatore intero a 32 bit (che probabilmente sarebbe di default), potrebbe riportare un numero intero a 32 bit per i pacchetti mancanti. Tuttavia, durante la lettura delle risposte, la risposta avrà necessariamente solo gli ultimi 16 bit del contatore. Quindi la risposta al numero progressivo 89805 sarà 89505 & 0xFFFF che è 24269.

    
risposta data 11.05.2013 - 06:53
fonte
2

So che questo è un vecchio argomento.

Ma grazie a tutti per questa risoluzione dei problemi. Tutti i passaggi mi hanno aiutato a risolvere un problema in cui ero in grado di eseguire il ping degli host ma non di connettermi tramite telnet.

La soluzione è stata piuttosto semplice (in seguito) rimossa tutte le cose inutili da qui (come menzionato da Zac)

Login:

~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / Preferenze di sistema > Utenti e amp; Gruppi > Elementi di login

Startup:

/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / /Library/Preferences/com.apple.loginitems.plist (raramente esiste)

Ancora una volta, grazie a tutti

    
risposta data 04.02.2014 - 10:02
fonte
1

Curioso problema considerando che persiste su Ethernet. Ho avuto un problema simile ma ho riscontrato che l'interferenza WiFi di altre reti era il problema. Il passaggio a una banda a 5 GHz ha risolto il problema, vale a dire che vale la pena provare.

    
risposta data 27.04.2013 - 05:35
fonte
1

Qualche suggerimento da /var/log/system.log?

come appare netstat -s?

La mia impressione dice delete / Library / Preferences / SystemConfiguration e riaggiorna manualmente le interfacce di rete.

Sembra che tu abbia già provato molte cose.

    
risposta data 02.05.2013 - 08:43
fonte
1

Sembra simile a questo?

link

Ho appena postato questo per Mavericks. Pensieri?

    
risposta data 25.10.2013 - 22:20
fonte
0

Suggerimenti per Mac OSX link   su connessioni disconnesse perché le ricerche DNS falliscono l'identificazione DCHP in sospeso   di un router ..

try configuring your Mac to use the OpenDNS (OpenDNS.ORG) servers 
instead of your ISPs DNS servers. 

Molto probabilmente il DNS e / o un'impostazione di accelerazione nelle impostazioni del modem e l'esclusione di quel DNS dovrebbero aiutare a risolvere il problema.

    
risposta data 27.04.2013 - 02:08
fonte
0

Questo ha un odore simile a un altro dispositivo sulla tua rete sta tentando di usare lo stesso tuo IP o qualche problema con DHCP.

Potresti vedere se riesci ancora a riprodurlo dopo averti assegnato un IP statico?

Vai a Preferenze di rete, scegli la tua interfaccia Ethernet, avanzata, TCP / IP

Cambia il menu a discesa "Configura IPv4" su "Manualmente"

Indirizzo IPv4: 192.168.1.150 (qualcosa di unico, non quello che DHCP ti aveva assegnato prima) Subnet Mask: 255.255.255.0 Router: 192.168.1.1

Salva

Quindi prova a riprodurre nuovamente il problema. Quando esegui questo test, assicurati che il Wi-Fi sia spento, quindi è in uso solo l'Ethernet. Questo ti aiuterà a restringerlo.

Se il problema persiste, è necessario scaricare Wireshark ( link ) avviare un'acquisizione, riprodurre il problema, salvare il file scarico e diamo un'occhiata.

Inoltre, che router / AP stai usando?

    
risposta data 14.05.2013 - 22:18
fonte
0

Due elementi da verificare correlati a questo causati dall'aumento del traffico LAN dovuto ai nuovi coinquilini.

  1. Sono presenti impostazioni QoS (Quality of Service) sul router e, in caso affermativo, come sono impostate? Il traffico di Skype sarà prioritario e se la WAN si sta saturando il router potrebbe rispondere chiudendo temporaneamente le connessioni con priorità inferiore.
  2. La CPU del router si sta sovraccaricando? Quando ho aggiornato il servizio via cavo da 1 Gbs DSL a 5 Gbs ho scoperto che il mio router semplicemente non riusciva a tenere il passo con il traffico aumentato e ha dovuto comprarne uno nuovo. Esamina le prestazioni del tuo router e verifica se questo potrebbe essere un problema. La maggior parte dei router dispone di recensioni dettagliate delle prestazioni disponibili su Internet; controlla e vedi come il tuo router è valutato rispetto alla tua capacità di servizio internet.
risposta data 16.05.2013 - 20:03
fonte
0

Ehi ragazzi stavo avendo lo stesso esatto problema, ma ho appena scollegato le cuffie che stavo usando e ho parlato con il mio amico per i primi 10 minuti e non è ancora caduto, quando prima era sceso a 20 secondi.

Il mio cavo per le cuffie è stato strappato, quindi potrebbe essere stato il problema, ma non so molto sull'indirizzo IP e sul ping, e questo mi è sembrato di aiuto. Se ci provi e non funziona, non incolparmi, perché ha risolto il mio problema.

    
risposta data 08.10.2013 - 23:21
fonte
0

The solution was rather simple (afterwards) removed all the unnecessary stuff from here (as zac mentioned)

Login:

~/Library/LaunchAgents/ ~/Library/LaunchDaemons/ System Preferences > Users & Groups > Login Items

Startup:

/Library/LaunchAgents/ /Library/LaunchDaemons/ /Library/StartupItems/ >/Library/Preferences/com.apple.loginitems.plist (rarely exists)

so che questo è un thread vecchio, ma farlo risolve il problema che avevo. A volte il mio Internet si disconnette e il ping si interrompe continuamente. Quello che risolverebbe il mio problema è di spegnere wi-fi o ethernet (che stavo usando sempre), quindi riattivarlo. Ovviamente questo risolverebbe solo temporaneamente il problema. Era strano perché ogni volta che il mio Mac Pro 4,1 avrebbe avuto questo problema, il mio mac portatile avrebbe perso anche ping. Era quasi come se il mio Mac Pro potesse far cadere la mia rete.

Ho provato così tante cose! sostituendo il modem, il router, chiamato isp, comprò usb in ethernet. nessuna di queste cose ha funzionato, fino a quando ho provato questo!

Ho fatto quello che ho menzionato sopra e ha finalmente risolto il problema !!

    
risposta data 11.02.2014 - 05:31
fonte
0

Ho avuto un problema simile e nel mio caso sembra essere causato da Tunnelblick, anche quando la VPN non era connessa. L'ho disinstallato (con il programma di disinstallazione, non solo trascinato nel cestino) e il problema è andato via.

    
risposta data 06.05.2015 - 14:53
fonte

Leggi altre domande sui tag