Recentemente, tive esse problema com minha conexão com a Internet no meu MacBook Pro, no início de 2011, executando o OS X 10.8.3: de tempos em tempos, a conexão "congela" por cerca de 5 segundos e depois volta.
Isso acontece tanto por Wi-Fi quanto por cabo Ethernet , e só acontece com a minha máquina quando está executando o OS X (não acontece com o Windows 7 na mesma máquina ou em qualquer outra máquina / dispositivo). Isso faz com que o Skype retire chamadas a cada 2 minutos ou mais, por isso é muito frustrante.
Executar ping no Google.com se parece com isso ao executar o OS X (existem centenas de pacotes que retornam em menos de 100ms (com alguns no intervalo 130) e, em seguida, são deixados de lado por alguns segundos) :
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: o MAC Wi-Fi da minha máquina é 68: a8: 6d: 29: cf: 8a (IP estático 192.168.1.250) e seu endereço Ethernet é 3c: 07: 54: 5a: e0: 44 (IP estático 192.168.1.251) . O IP da LAN do roteador é 192.168.1.1 e o IP da WAN é 85.61.155.224.
Na próxima captura de tela, é possível ver, durante uma chamada do Skype:
ping 192.168.1.1
no canto superior esquerdo.ping 85.61.155.224
no canto inferior esquerdo.ping google.com
no canto inferior direito.- os comandos
arp -an
earp -ad
executados.
Quando executei o arp -ad
comando no momento em que a conexão foi perdida, a lista não mostrava nenhum endereço. Parecia assim:
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$
Não tenho conhecimento suficiente para seguir as instruções de mike sobre como obter e compilar a fonte do mtr
comando.
É assim que as coisas ficam quando é pior:
A corrida netstat -s
oferece:
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
A corrida netstat -I en1
oferece:
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 - -
A corrida ifconfig -a
oferece:
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
O que eu penso:
- Não é um problema de Wi-Fi, porque também acontece por cabo.
- Não é um problema de roteador / ISP porque outros dispositivos e máquinas não têm nenhum problema.
- Não é um problema de máquina, porque só acontece ao executar o OS X.
- Portanto, deve ser um problema do OS X.
O que eu tentei:
- Reinicie, desligue.
- Ligue e desligue o AirPort, diferentes cabos Ethernet.
- Reparar permissões.
- Redefina a PRAM.
- Limpe todos os caches do sistema e do usuário com o Onyx.
Nota estranha: Por algum motivo estranho, o problema parece piorar quando uma chamada do Skype está ocorrendo.
Eu gostaria de ter idéias sobre como abordar esta questão.
Respostas:
Quando suas conexões começam a atingir o tempo limite, você pode fazer isso
arp -an
no Terminal.app e verificar se ainda possui todos os endereços MAC na tabela ARP? como em - o endereço MAC do seu roteador ou o host que você está tentando executar ping?Se você o fizer (e tiver tempo antes que ele comece a funcionar novamente), poderá liberar a tabela arp (
sudo arp -ad
) e verificar se o endereço MAC do seu roteador aparece na tabela ARP novamente?Além disso, tente executar um ping no endereço IP da LAN do seu roteador em uma sessão do Terminal e talvez um ping no endereço IP da WAN do seu roteador em outro enquanto estiver no Skype. Veja se todos eles começam a atingir o tempo limite ou apenas um deles. Mais uma ferramenta que eu acho útil
mtr
: você pode precisar obter o código-fonte e compilá-lo por conta própria ou usar o fink / macports ou outro gerenciador de pacotes. Quando você o obtiver, basta executá-lo em um destino em algum lugar da Internet e ele mostrará qual salto para de responder.Como instalar o software a partir de fontes (como mtr) Requer que o Xcode seja instalado :
gzip -dc filename.tar.gz | tar -xvf -
, que normalmente cria um novo diretório no diretório atual e coloca o conteúdo do arquivo morto)./configure --prefix=/usr/local
(observe que eu gosto de instalar o software da fonte/usr/local
para mantê-lo longe dos binários instalados como parte do sistema; a--prefix=/usr/local
opção de configurar fará exatamente isso)make
sudo make install
fonte
mtr
é uma excelente ferramenta. Infelizmente aqui o problema é muito menos distante. O problema parece estar entre o MacOS X e o 192.168.1.1. Não há necessidade de caçar em direção ao horizonte da Internet ☺.Você pode primeiro verificar se realmente está usando a interface de rede:
Você poderia observar a saída dos seguintes comandos (se en0 é o nome da interface de rede da sua placa Ethernet):
Para ajudar a localizar o problema, você pode criar um local específico apenas com a sua placa Ethernet ativada e, se possível, usando apenas IPv4 ou IPv6, mas não os dois:
Você pode executar a seguinte extração de possíveis erros de hardware ou driver:
(não se assuste, você pode encontrar muitas informações sobre os canais Wi-Fi).
A seguinte mensagem exibida pelo seu netstat:
significa que você é realmente o alvo de uma inundação tcp syn boba (que é um ataque de negação de serviço (DOS)).
Quando seu:
engasga por 6s, você pode executar:
fonte
ping 192.168.1.1
(que não fará nenhuma solicitação de DNS).Automatic
configuração.ifconfig -a
?Automatic
local em Preferências de rede, criei um novo local para casa e trabalho e parece ter parado os tempos limite do bloco.Estou com esse problema há muito tempo (começando após uma atualização para o Mavericks) e, depois de meses de pesquisa, acho que finalmente encontrei uma solução.
Primeiro de tudo, há muitas pessoas com o mesmo problema nos fóruns da Apple:
Portanto, esse é um problema conhecido e eu realmente não sei por que a Apple ainda não forneceu uma correção para isso. Nos tópicos listados acima, existem muitas sugestões para corrigir isso, mas a maioria delas não funcionou. Alguns corrigem o problema temporariamente:
sudo rm -rf /Library/Preferences/SystemConfiguration
Após essas medidas, a conexão de rede é muito melhor e não sinto quedas por várias horas ou, às vezes, até dias. Mas os problemas sempre voltam.
Esta pergunta e as dicas de que o problema pode estar relacionado ao ARP me levaram a iniciar mais pesquisas e encontrei esta página , que descreve o bug em detalhes e também contém um patch, que cito aqui:
Consulte o link fornecido para obter uma explicação detalhada da correção, que deve ser incluída em uma atualização futura do sistema operacional para Yosemite pela Apple. Desativa solicitações ARP unicast, que causam confusão com alguns equipamentos de rede, como o roteador doméstico.
Após aplicar a correção e reiniciar, deve-se verificar se
retorna
net.link.ether.inet.arp_unicast_lim: 0
. Se o número não for igual a zero, a correção não foi aplicada corretamente.Posteriormente, encontrei outro tópico nas comunidades da apple que contém a mesma solução: Mavericks e ARP com falha, causando quedas na rede! Bem, depois de saber qual é o problema, encontrar a solução correta é muito mais fácil.
fonte
Primeiro, vejo o dropbox sendo executado na sua barra de menus; você já desativou isso?
Segundo, tente remover qualquer outro item de inicialização / login. Olhar dentro:
Entrar:
Comece:
fonte
Há muitas informações aqui sobre a solução de problemas e o diagnóstico final, mas às vezes, na solução de problemas, é divertido voltar ao básico e questionar algumas suposições.
Como mencionei em um comentário, isso se parece muito com um roteador QOS, devido ao fato de sua máquina exceder temporariamente alguma largura de banda ou limite de taxa de pacote.
E se você estiver executando diferentes padrões, volumes e quantidades de tráfego de rede no OS X, em oposição ao Windows, e essa é a causa real, não os drivers de hardware ou o software?
Eu esperava que a execução do OS X esteja correlacionada com as suas observações, mas e se não for a causa das pausas temporárias da rede.
Você já tentou pesquisar e se algum filtro de QOS e alterações de roteamento forem implementadas pelo seu provedor de rede? Você já pensou em encapsular todo o tráfego em outro computador (ssh ou VPN) para descartar filtros triviais. (Se o provedor estiver realizando uma inspeção profunda de pacotes ou um destino e uma verdadeira limitação de taxa - talvez você não consiga escapar desses curtos tempos limite.)
Espero que haja uma resposta que você possa encontrar observando os detalhes da rede (e todos aprenderemos algo explorando essas opções) - mas certifique-se de considerar também que suas ferramentas de medição e tráfego adicional para fazer ping / cutucar podem afetando as contagens de tráfego e aumentando a probabilidade do Skype cair para você. Os roteadores que eu configuro são programados para descartar o tráfego ICMP antes de todo o outro tráfego, desde que a capacidade seja reduzida - prefiro que o ping falhe e outros pacotes sejam concluídos. Seu ISP e provedor de rede podem ter configurado as coisas da mesma forma.
fonte
Além de todo o material aqui, convém garantir que a detecção automática de proxy não esteja ativada (assim como a configuração automática de proxy). Isso tende a causar mais problemas do que não e geralmente não é necessário.
fonte
Com todas as excelentes informações de diagnóstico nesta questão, você reduziu bastante as possibilidades.
Para começar, seus pings para 192.168.1.1 isolam bastante o problema no seu roteador, computador ou LAN. Este não é um problema com o DNS ou seu ISP.
Estou muito perturbado com os resultados dos seus testes de ping para 192.168.1.1. Você fez algo estranho ao configurá-los?
Por exemplo, você tem pings bem-sucedidos com números de sequência ICMP de 24267, 24268 e 24269, depois 3 tempos limite e sucesso novamente com ICMP 24273. Portanto, os números dos sucessos parecem corretos. No entanto, os números dos tempos limite são completamente diferentes. Eu esperaria ver tempos limite de solicitação do ICMP 24270, 24271 e 24272, mas, em vez disso, os tempos limite relatam ICMP 89806, 89807 e 89808. Nunca vi isso antes e, portanto, para mim, isso sugere que você tem uma pilha de rede quebrada. computador. Talvez uma extensão demais. Alguma chance de você ter o Netgear Genie instalado? Ou talvez um software VPN?
De qualquer forma, eu diria que é hora de começar a desativar os "aprimoramentos" para ver se você pode encontrar um culpado instalado no computador.
Editar
OK, mistério resolvido. O número de sequência do ICMP é um campo de 16 bits. Tratado como um número inteiro não assinado, isso significa que ele tem um valor máximo de 65.535 e, em seguida, volta a zero. Portanto, se o programa ping local estiver mantendo um contador inteiro de 32 bits (o que provavelmente faria por padrão), ele poderá relatar um número inteiro de 32 bits para pacotes ausentes. No entanto, ao ler as respostas, a resposta necessariamente terá apenas os últimos 16 bits do contador. Portanto, a resposta ao número de sequência 89805 será 89505 & 0xFFFF, que é 24269.
fonte
Eu sei que este é um tópico antigo.
Mas obrigado a todos por esta solução de problemas. Todas as etapas me ajudaram a solucionar um problema em que eu era capaz de executar ping nos hosts, mas não conectar a eles via telnet.
A solução foi bastante simples (depois) removeu todo o material desnecessário daqui (como o zac mencionou)
Entrar:
~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / Preferências do sistema> Usuários e grupos> Itens de logon
Comece:
/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / /Library/Preferences/com.apple.loginitems.plist (raramente existe)
Mais uma vez, obrigado a todos
fonte
Problema curioso, considerando que persiste na Ethernet. Eu tive um problema semelhante, mas achei que a interferência WiFi de outras redes era o problema. Mudar para uma banda de 5 GHz resolveu o meu problema, o que acho que vale a pena tentar.
fonte
Alguma dica de /var/log/system.log?
como é o netstat -s?
Meu palpite diz excluir / Library / Preferences / SystemConfiguration e adicionar novamente as interfaces de rede manualmente.
Parece que você já tentou muitas coisas.
fonte
Parece semelhante a isso?
https://discussions.apple.com/thread/5483424?tstart=0
Acabei de publicar isso para Mavericks. Pensamentos?
fonte
Dicas para Mac OSX http://hints.macworld.com/article.php?story=20080605143917233 em conexões interrompidas porque as pesquisas de DNS falham, dependendo da identificação DCHP de um roteador.
Provavelmente, o DNS e / ou uma configuração de aceleração nas configurações do modem e ignorando que o DNS ajude a resolver seu problema.
fonte
Parece que outro dispositivo da sua rede está tentando usar o mesmo IP que você ou algum problema com o DHCP.
Você conseguiu ver se ainda pode reproduzi-lo após atribuir a si mesmo um IP estático?
Vá para Preferências de Rede, escolha sua interface Ethernet, avançada, TCP / IP
Altere o menu suspenso "Configurar IPv4" para "Manualmente"
Endereço IPv4: 192.168.1.150 (algo único, não o que o DHCP havia lhe atribuído antes) Máscara de sub-rede: 255.255.255.0 Roteador: 192.168.1.1
Salve
Em seguida, tente reproduzir o problema novamente. Ao fazer esse teste, verifique se o Wi-Fi está desligado, para que apenas sua Ethernet esteja em uso. Isso ajudará a reduzi-lo.
Se você ainda estiver com o problema, baixe o Wireshark ( http://www.wireshark.org/ ) inicie uma captura, reproduza o problema, salve o despejo e deixe-nos dar uma olhada.
Além disso, qual roteador / ponto de acesso você está usando?
fonte
Duas coisas a verificar que estão relacionadas a isso são causadas pelo aumento do tráfego da LAN devido a novos colegas de quarto.
fonte
Ei pessoal, eu estava tendo o mesmo problema exato, mas desconectei os fones de ouvido que estava usando e conversei com meu amigo nos primeiros 10 minutos e ele ainda não caiu, quando antes caiu em 20 segundos.
O cabo do meu fone de ouvido foi rasgado, por isso pode estar causando o problema, mas eu não sei muito sobre o endereço IP e o ping, e isso apenas me ajudou. Se você tentar e ele não funcionar, não me culpe, porque resolveu o meu problema.
fonte
Eu sei que este é um tópico antigo, mas isso corrigiu o problema que eu tinha. Minha internet às vezes desconectava e os ping diminuíam o tempo todo. O que resolveria o meu problema é desligar o wi-fi ou ethernet (que eu estava usando) e reativá-lo. É claro que isso apenas resolveria temporariamente o problema. Era estranho, porque sempre que meu mac pro 4,1 apresentava esse problema, meu laptop mac também perdia pings. Era quase como se meu Mac Pro derrubasse minha rede.
Eu tentei tantas coisas! substituindo o modem, o roteador, chamado isp, comprou usb para ethernet. Nenhuma dessas coisas funcionou, até que eu tentei isso!
Eu fiz o que é mencionado acima e finalmente resolveu o problema!
fonte
Eu tive um problema semelhante e, no meu caso, parece ter sido causado pelo Tunnelblick, mesmo quando a VPN não estava conectada. Eu o desinstalei (com o desinstalador, não basta arrastar para a Lixeira) e o problema desapareceu.
fonte