Problema intrigante de conexão no OS X


33

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 -ane arp -adexecutados.

Quando executei o arp -adcomando 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 mtrcomando.

captura de tela das operações

É assim que as coisas ficam quando é pior:

captura de tela da pior situação

A corrida netstat -soferece:

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 en1oferece:

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 -aoferece:

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.


1
Eu também experimento isso! É muuuuito irritante. Não tenho certeza se isso foi marcado com 10.8.3. Meu Mac tem MBA em meados de 2012. No entanto, os congelamentos da rede podem durar 15 segundos.
gentmatt

2
Verifique se o seu Skype está definido como: Incoming Connection Porto: 12794
Ruskes

1
Eu adicionei instruções de instalação para o MTR na resposta de mike
Alexander - Restabelecer Monica

2
OK então - mais algumas perguntas. Você possui um roteador e um ponto de acesso separados ou todos eles estão integrados? Se eles estiverem separados - você tem um alternador entre o roteador e o ponto de acesso? Também - se você estiver conectado com Ethernet - você se conectar ao mesmo switch (Atenção - Eu ainda significa um dispositivo separado)
mike

2
Miguel: o fato de você não parecer afetado por isso em nenhuma outra rede para mim parece indicar que o problema está realmente entre o seu roteador e o Mac. Não concordo com os outros que o problema está no seu ISP. Quando o problema ocorre, você não vê um endereço MAC do seu roteador na sua tabela ARP. Essa é uma camada inferior à do DHCP, roteamento, etc., pois todas elas requerem conectividade da Camada 2 para funcionar. Você não tem a conectividade da camada 2 funcionando quando o problema se manifesta. (TBC)
mike

Respostas:


13

Quando suas conexões começam a atingir o tempo limite, você pode fazer isso arp -anno 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 :

  • faça o download do arquivo de origem (normalmente .tar.gz ou .tar.bz2)
  • descompacte o arquivo baixado (por exemplo, na execução do Terminal.app 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)
  • navegue até a pasta obtida no terminal
  • executar ./configure --prefix=/usr/local(observe que eu gosto de instalar o software da fonte /usr/localpara mantê-lo longe dos binários instalados como parte do sistema; a --prefix=/usr/localopção de configurar fará exatamente isso)
  • corre make
  • corre sudo make install
  • feito!

Feito isso, em breve editaremos a pergunta com os resultados.
Mike D.

Quando eu faço 'arp -an' após excluir a tabela, ele não lista o roteador até que a conexão seja reiniciada.
Mike D.

1
→ mike: 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 ☺.
dan

Este comando realmente me ajudou.
Jåddå

6

Você pode primeiro verificar se realmente está usando a interface de rede:

ifconfig -a

Você poderia observar a saída dos seguintes comandos (se en0 é o nome da interface de rede da sua placa Ethernet):

netstat -I en0

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: Localização apenas com Ethernet ligada

Você pode executar a seguinte extração de possíveis erros de hardware ou driver:

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

(não se assuste, você pode encontrar muitas informações sobre os canais Wi-Fi).

A seguinte mensagem exibida pelo seu netstat:

44620 embryonic connections dropped

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:

ping 192.168.1.1

engasga por 6s, você pode executar:

netstat -m

Quando 192.168.1.1 engasga, 'netstat -m' não mostra nada fora do comum. A propósito, o grep parece não encontrar '/var/log/kernel.log'. Estou editando a pergunta com os resultados de 'netstat -I en1' (estou usando en1 agora, que é meu aeroporto, en0 está inativo). Qual pode ser o motivo do ataque do DOS?
Mike D.

2
→ Miguel: para simplificar sua análise do seu problema, faça uma nova rede conf. com apenas a interface Ethernet ativada. Depois, mantenha dentro de uma janela a ping 192.168.1.1(que não fará nenhuma solicitação de DNS).
dan

→ Miguel: você pode ter sido relutantemente o autor do seu ataque do DOS ☹, mas isso ainda está para ser confirmado. Suspeito de um loop de rede causado por uma Automaticconfiguração.
dan

1
→ Miguel: você poderia nos fornecer um ifconfig -a?
dan

1
Isso resolveu meu problema: mudei o Automaticlocal em Preferências de rede, criei um novo local para casa e trabalho e parece ter parado os tempos limite do bloco.
Alex Lynham

4

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:

  • Desconecte e reconecte a rede
  • O velho amigo: reiniciar
  • Remova a pasta que contém a configuração de rede: 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:

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

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

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

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.


3

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:

  1. ~ / Biblioteca / LaunchAgents /
  2. ~ / Biblioteca / LaunchDaemons /
  3. Preferências do sistema> Usuários e grupos> Itens de login

Comece:

  1. / Biblioteca / LaunchAgents /
  2. / Biblioteca / LaunchDaemons /
  3. / Biblioteca / StartupItems /
  4. /Library/Preferences/com.apple.loginitems.plist (raramente existe)

Não tentei desativar o Dropbox, isso seria útil? E também, você poderia explicar o motivo da remoção desses itens? Obrigado!
Mike D.

1
Você deseja isolar se o problema está no OS X ou em um software que foi adicionado após a instalação inicial. Coisas como o dropbox que faz conexões de rede assim que a conta do usuário é carregada ou o software antivírus que normalmente é executado em todas as contas de usuário podem estar reservando uma porta ou contribuindo para o problema.
Zac

Ok, eu vou fazer isso e postarei aqui os resultados amanhã.
Mike D.

→ Miguel: Dropbox não poderia ser seu problema. O Dropbox está simplesmente executando o 443 / tcp como qualquer outra navegação na web. Porém, caso você queira fazer um sniffing na rede (Wireshark ou tcpdump) parando o Dropbox, você removerá um monte de tráfego tcp. Portanto, isso ajudará você a "ver" qualquer mau comportamento.
dan

1
@ Miguel, mais alguns palpites. 1. você entrou em contato com seu ISP para verificar se eles podem verificar a qualidade da linha? 2. Que tal configurar uma conta de usuário de teste para ver se o problema se move. Uma terceira sugestão é verificar o sistema - coisas como verificação de permissões - diagnósticos da máquina. 4. você pode trocar componentes - use o computador no local de um amigo - peça emprestado o roteador de seus amigos - e remova todos os outros equipamentos de rede do seu sistema.
David DelMonte

2

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.


Entendo ... mas nada mudou na minha atividade de rede nos últimos 5 anos. Esse problema começou cerca de um mês atrás e não consigo encontrar nenhuma correlação, exceto que foi há cerca de um mês quando dois colegas se mudaram. Mas eu executei testes de ping em suas máquinas e eles não enfrentam esse problema. Não conheço nenhum filtro QOS, mas tentarei descobrir.
Mike D.

O Skype está hospedando uma ligação quase 24 horas por dia, 7 dias por semana na minha máquina ... hoje eu vou desligar todos os pings, etc., para ver se algo muda na próxima vez em que a conexão cair (porque ainda posso dizer se cai ouvindo o áudio Recebo da chamada do Skype)
Mike D.

2

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.

Preferências do Sistema


Obrigado pelo conselho, eles já estavam desligados :(
Mike D.

2

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.


Oi. Eu não fiz nada de estranho ... é apenas um 'sudo ping 192.168.1.1' ... Entendo o que você está dizendo sobre os números de sequência do ICMP ... Não tenho idéia do porquê disso ... talvez o o ping estava rodando por muito tempo? (está em funcionamento há dias) ... Não faço ideia. Além disso, minha configuração de rede é bastante simples e uso a mesma configuração há anos sem problemas.
Mike D.

1
Software que está sempre sendo executado em segundo plano e que pode ter algo a ver com isso: Little Snitch, Dropbox, Skype e todas as coisas do OS X ... mas nada de novo, e o problema começou cerca de um mês atrás. Uma coisa que eu suspeito é que foi cerca de um mês atrás, quando dois novos colegas de quarto se mudaram. Eu executei testes de ping em seus computadores e eles não estavam tendo esse problema.
Mike D.

@ Miguel, definitivamente remova o Little Snitch, pois esse é exatamente o tipo de software que pode estar criando esse problema. Se você não tiver uma configuração complicada, eu diria que a desinstale completamente e esvazie o lixo para garantir que ele se foi e reinicie e veja se isso resolve o problema.
Old Pro

Ok, vou desinstalá-lo completamente e ver o que acontece (mas eu o uso há anos sem problemas).
Mike D.

Engraçado ... 24269 no binário é 0000 0101 1110 1100 1101. 89806 no formato binário é 0001 0101 1110 1100 1110. No entanto, se pegarmos o 24269 e apenas trocarmos o bit 16, obteremos 0001 0101 1110 1100 1101 = 89805. Para mim, parece inteiro assinado versus não assinado, portanto, é uma apresentação puramente numérica. Pode ser que o dispositivo Miguel é ping usos sem assinatura inteiros em vez de assinados (ou o outro ao redor way) ...
mike

2

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


1

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.


Antes de mudar de canal de rede, porque você acha que tem um problema de interferência, basta diagnosticá-lo por via clérigo. Isso é bem fácil: use istumbler.net . Você verá a verdade diretamente nos olhos ☺.
dan

1

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.


Olá Miguel, adicionando mais vodu depois de ver suas capturas de tela. você poderia tentar estas três coisas: 1: desativar o bluetooth, 2: testar as interfaces de rede 1 por 1? 3: apenas para confirmar, você está usando drivers de rede de ações, certo?
epoon 5/05

O system.log é enorme ... Eu procurei palavras específicas, mas não consegui encontrar nada relevante :(
Mike D.

Vou editar a pergunta adicionando os dados que o netstat -s me forneceu.
Mike D.

Eu já apaguei toda a configuração de rede. e acrescentou tudo manualmente, mas sem sorte. O Bluetooth sempre esteve desligado. Estou usando drivers de rede de ações. Todas as interfaces de rede dar exatamente os mesmos resultados: a perda momentânea da conexão de vez em quando :(
Mike D.

1
O erro de pacote icmp e ip me preocupa. separadamente, instale uma nova cópia do OSX e inicialize-a via USB. Isso isolará sua instalação do OSX. se uma cópia nova continuar com erros, bem, temos um erro de hardware - quem sabe, pode haver apenas drivers OSX que a acionarão. Mostrar que aparece problemáticos na nova instalação, e maçã deve corrigi-lo para você
epoon

1

Parece semelhante a isso?

https://discussions.apple.com/thread/5483424?tstart=0

Acabei de publicar isso para Mavericks. Pensamentos?


1
Embora esse link possa responder à pergunta, é melhor incluir aqui as partes essenciais da resposta e fornecer o link para referência. As respostas somente para links podem se tornar inválidas se a página vinculada for alterada.
grg

Vou tentar dar uma olhada na solução no link para ver se ela também me ajuda. Vou postar de volta.
Mike D.

0

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.

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

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.


5
Isso não causaria esse problema. o ping faz uma pesquisa de DNS uma vez (google.com -> 173.194.34.196 nesse caso) e, em seguida, use o endereço IP.
Gordon Davisson

Vai fazer isso e informar de volta.
Mike D.

1
→ Blip: este não é um problema relacionado ao DNS. O ping em direção ao roteador com um endereço IP não produz nenhum paquer de udp, apenas um eco bobo de icmp.
dan

0

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?


0

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.

  1. Existem configurações de QoS (qualidade de serviço) no roteador e, em caso afirmativo, como elas são definidas? O tráfego do Skype seria priorizado e, se a WAN estiver saturada, o roteador poderá responder fechando temporariamente as conexões de menor prioridade.
  2. A CPU do roteador está simplesmente ficando sobrecarregada? Quando atualizei de 1 Gbs DSL para 5 Gbs de serviço a cabo, descobri que meu roteador simplesmente não conseguia acompanhar o aumento do tráfego e precisava comprar um novo. Investigue o desempenho do seu roteador e veja se isso pode ser um problema. A maioria dos roteadores possui análises detalhadas de desempenho disponíveis na Internet; verifique e veja como o seu roteador é classificado em comparação com a capacidade do serviço de Internet.

0

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.


0

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)

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!


0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.