Intrigante problema de conexión en OS X

Recientemente he tenido este problema con mi conexión a Internet en mi MacBook Pro de principios de 2011 con OS X 10.8.3: de vez en cuando, la conexión se "congela" durante unos 5 segundos y luego vuelve.

Ocurre tanto a través de Wi-Fi como por cable Ethernet , y solo le sucede a mi máquina cuando ejecuta OS X (no sucederá cuando ejecute Windows 7 en la misma máquina o en cualquier otra máquina/dispositivo). Hace que Skype corte llamadas cada 2 minutos más o menos, por lo que es muy frustrante.

Hacer ping a Google.com se ve así cuando se ejecuta OS X (hay cientos de paquetes que regresan en menos de 100 ms (con algunos en el rango de 130), luego se caen durante varios 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: la MAC Wi-Fi de mi máquina es 68:a8:6d:29:cf:8a (IP estática 192.168.1.250) y su dirección Ethernet es 3c:07:54:5a:e0:44 (IP estática 192.168.1.251) . La IP LAN del enrutador es 192.168.1.1 y su IP WAN es 85.61.155.224.

En la siguiente captura de pantalla se puede ver, durante una llamada de Skype:

  • ping 192.168.1.1en la parte superior izquierda.
  • ping 85.61.155.224en la parte inferior izquierda.
  • ping google.comen la parte inferior derecha.
  • los comandos arp -any arp -adejecutados.

Cuando ejecuté el arp -adcomando en un momento en que se perdió la conexión, la lista no mostró ninguna dirección. Se veía así:

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$

No tengo suficiente conocimiento para seguir las instrucciones de mike sobre cómo obtener y compilar la fuente del mtrcomando.

captura de pantalla de las operaciones

Así es como se ven las cosas cuando es peor:

captura de pantalla de la peor situación

Correr netstat -sda:

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

Correr netstat -I en1da:

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

Correr ifconfig -ada:

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

Lo que pienso:

  • No es un problema de Wi-Fi porque también ocurre por cable.
  • No es un problema de enrutador/ISP porque otros dispositivos y máquinas no tienen problema.
  • No es un problema de la máquina porque solo ocurre cuando se ejecuta OS X.
  • Por lo tanto, debe ser un problema de OS X.

Lo que probé:

  • Reiniciar, apagar.
  • Encender y apagar AirPort, diferentes cables Ethernet.
  • Permisos de reparación.
  • Reinicie el COCHECITO.
  • Borre todos los cachés del sistema y del usuario con Onyx.

Nota extraña: por alguna extraña razón, el problema parece empeorar cuando se realiza una llamada de Skype.

Agradecería amablemente ideas sobre cómo abordar este problema.

¡Yo también experimento esto! Es tan molesto. No estoy seguro si esto comenzó con 10.8.3. Mi Mac es un MBA de mediados de 2012. Sin embargo, los bloqueos de la red pueden durar hasta 15 segundos.
Verifique si su Skype está configurado en: Puerto de conexión entrante: 12794
Mi skype está configurado en el puerto 15973
Agregué instrucciones de instalación para MTR en la respuesta de Mike
Me di cuenta de que, al menos una vez, la IP WAN del enrutador cambió después de una pérdida masiva de conexión. ¡Lo que es sorprendente es que otros dispositivos no tienen absolutamente ningún problema!
Bien, entonces, algunas preguntas más. ¿Tiene un enrutador y un punto de acceso separados, o están todos integrados? Si están separados, ¿tiene un interruptor entre el enrutador y el punto de acceso? Además, si está conectado con Ethernet, ¿se conecta al mismo conmutador (tenga en cuenta que todavía me refiero a un dispositivo separado)
Mi configuración es bastante simple: solo un enrutador (un livebox 2). Probé diferentes configuraciones Wi-Fi y todos los puertos Ethernet sin suerte. Esto comenzó a suceder hace aproximadamente 2 semanas y no tengo ni idea de qué podría haberlo desencadenado. Algunos días son peores que otros, sucede a diferentes horas... Parece que no puedo encontrar un patrón.
¿Cómo es su configuración de DHCP? ¿Es posible que tenga una dirección IP asignada estáticamente que esté en conflicto con otra dirección estática o con una proporcionada por DHCP?
El servidor DHCP está habilitado pero, en un esfuerzo por tratar de resolver el problema, configuré direcciones IP estáticas para mí y las otras computadoras en la red.
Cuando esto sucede, ¿puede hacer ping a cualquiera de los otros dispositivos en la misma LAN? No creo que el problema sea con DHCP ni nada en la capa 3. Creo que el problema está en la capa 2; por alguna razón, su enrutador/punto de acceso deja de responder al tráfico de la Capa 2 desde su Mac. Si bien entiendo que no tiene los mismos problemas con otros dispositivos, para mí apunta al problema con su livebox 2. ¿Tiene problemas similares cuando su Mac está conectada a otra conexión Wifi u otra conexión Ethernet? (por ejemplo, en el trabajo, en casa de un amigo, etc.)?
¿Está utilizando la misma dirección IP para Windows 7? Si no, pruébalo. Su netstat muestra una cantidad muy alta de intentos de conexión incorrectos. ¿Alguna idea de por qué? En este punto, creo que necesita configurar la captura de paquetes para ver qué sucede en el cable cuando se agota el tiempo de espera. Visite support.apple.com/kb/HT3994 para obtener instrucciones o considere usar sabrosococoabytes.com/cpa . En particular, quiero ver si, durante la interrupción, la computadora aún envía pings al enrutador y si hay respuestas de ping en el cable que se envían a una dirección MAC de Ethernet diferente.
→ Miguel: excelente resolución de problemas de red ☺ ! Claramente, el ping interno hacia su enrutador (192.168.1.1) es suficiente para demostrar que el problema se encuentra entre MacOS X y su enrutador. ¿Está utilizando la Automaticubicación?
→ gentmatt y Miguel: ¿podría intentar cambiar a MacOS X 10.8.2 y verificar con un ping local si experimenta el mismo agujero de 6 s (o más)?
daniel Azuelos: Eliminé todas mis ubicaciones y configuré una nueva ubicación a la que llamé "HOME" con solo Ethernet y Airport. Configuré una IP estática en mi enrutador para Ethernet y otra para Aeropuerto e ingresé todo manualmente en la configuración de red.
Old Pro: intentaré lo que sugieres y publicaré los resultados lo antes posible. ¡Gracias!
@mike: este problema ocurre solo en esta red... Salí ayer y revisé las redes públicas para encontrar que no tenía este problema. Apunta a algún tipo de mala comunicación entre OS X y mi enrutador.
→ Miguel: no uses 2 interfaces diferentes en MacOS X para analizar un problema de red: solo investiga una a la vez. Comience con el de Ethernet. Su problema parece típico de la Automaticconfiguración de red maldita.
Todos: Muchas gracias por sus respuestas, especialmente a MIKE, OLD PRO y DANIEL AZUELOS. Dado que el tiempo de la recompensa ha terminado y el problema persiste, lancé los dados entre ustedes tres y DANIEL AZUELOS obtendrá el +50... PERO abriré otra recompensa de inmediato, así que tengan paciencia conmigo.
Esta es la firma de una falla de enrutamiento descendente. Específicamente, mi conjetura es que una tabla de enrutamiento cambia o un filtro QOS decide poner en cola sus paquetes y entregar otros paquetes de mayor prioridad preferentemente durante un período de tiempo. Tienes una gran ayuda aquí, pero pasaría un poco de tiempo con tu proveedor de red para entender cuándo y cómo acelerarán tu conexión. Es posible que pueda probar esto indirectamente restringiendo severamente otro tráfico o enrutando este tráfico a través de una VPN a un centro de datos en otro lugar para evitar activadores QOS elementales.
Miguel: el hecho de que no parezcas estar afectado por esto en ninguna otra red me parece indicar que el problema es realmente entre tu enrutador y la Mac. No estoy de acuerdo con los demás en que el problema está en tu ISP. Cuando ocurre su problema, no ve una dirección MAC de su enrutador en su tabla ARP. Esta es una capa más baja que DHCP, enrutamiento, etc., ya que todos requieren conectividad de Capa 2 para funcionar. No tiene la conectividad de Capa 2 funcionando cuando se manifiesta el problema. (por confirmar)
(Parte 2): Lo único que verificaría (si su enrutador lo permite) es iniciar sesión en el enrutador desde otro dispositivo y ver si puede borrar y luego ver la dirección MAC de su Mac en el enrutador mientras ocurre el problema (tan similar a lo que has hecho en tu MBP). Esto mostrará si hay conectividad unidireccional o no hay conectividad. Tuve problemas similares con un punto de acceso de Linksys: dejaba de reenviar tramas de Ethernet (por lo que afectaba a la capa 2) y, como resultado, TODO dejaba de funcionar. Pude solucionar el problema cambiando el punto de acceso a la banda de 5 GHz.
@mike Lo tengo... definitivamente es un problema entre la Mac y el enrutador. Puedo intentar verificar la MAC de mi Mac desde otro dispositivo en el momento de la caída de la conexión... pero, ¿hay alguna otra forma? Tengo que pedirles a mis compañeros de cuarto que cooperen para esto y ninguno de nosotros tiene mucho tiempo libre en el trabajo.
@mike, ¿crees que Little Snitch podría ser una posible causa? Lo he estado usando durante años y nunca me había pasado esto hasta ahora... pero tal vez mi LAN esté más ocupada ahora que se mudaron 2 personas más... ¿Qué opinas?
Miguel, no estoy seguro acerca de Little Snitch, nunca lo usó. Sin embargo, no lo creo, ya que parece que el problema está en la capa 2. Por lo general, cuando las aplicaciones hacen algo a través de la red, usan la pila TCP/IP proporcionada por el sistema (ya sea mediante llamadas al sistema o uno de muchos Frameworks). Hay excepciones, los firewalls y los sniffers son buenos ejemplos. Todavía pensaría que si Little Snitch pasa por alto la pila TCP/IP del sistema, lo hace en la Capa 3. Verificar si la dirección Mac de su MBP está visible en un dispositivo diferente (otra PC o MAC) es una buena idea (TBC)
(Parte 2) ... solo asegúrese de intentar ejecutar ping tanto en el enrutador como en esa otra caja al mismo tiempo. El hecho de que no parece experimentar el mismo problema en otra red confirma que el problema es local para su configuración. Mencionó que su LAN está más ocupada después de que las otras dos personas se mudaron. ¿Significa que no hubo problemas como este antes, o no los experimentó con tanta frecuencia pero todavía estaban allí? Esto podría significar que una interfaz en su enrutador está algo sobrecargada. ¿Qué marca y modelo de enrutador es?
Lo único que agregaría aquí es intentar ejecutar wireshark : es un analizador de paquetes muy bueno (¿probablemente el mejor?) Y gratuito. Puede ejecutarlo en su máquina y ver si está enviando marcos y paquetes a su interfaz de red mientras ocurre el problema (por ejemplo, lo que está buscando son solicitudes ARP después de haber vaciado el caché arp), y si está recibir alguna respuesta. Si su problema es causado por marcos dañados, lo verá. También deberá obtener XQuartz si desea una GUI (que bien vale la pena).
@mike, ¿qué opina del hecho de que los tiempos de espera de ping informan números de secuencia ICMP de una secuencia diferente a los éxitos de ping? apple.stackexchange.com/a/91069/21703
→ mike: Wiresharkes una gran herramienta pero reservada para los gurús que dominan arp, ifconfigy opciones ☺ netstat.ping
¿Ocurre esto cuando está completamente en otra red, como en la escuela o el trabajo? Si inicia su MacBook Pro en modo de recuperación (arranque presionando cmd + R), ¿ocurre allí a través de Safari y/o Terminal? Si la respuesta a cualquiera de estos es no, haría una copia de seguridad del sistema y reinstalaría el sistema operativo.
→ Miguel: ¿Tu problema está analizado, arreglado? ¿Aún necesitas ayuda? ¿Cuál es la mejor respuesta?
@danielAzuelos No se ha solucionado el problema. Dejé de hacer llamadas de Skype a ciertas horas.
@danielAzuelos No hay una mejor respuesta, pero las respuestas que recibieron las recompensas son las que siento que están más cerca de la solución.
→ Miguel: leyendo una vez más tu descripción original del problema, estoy convencido de que esto es típico de la Automaticconfiguración de ubicación de MacOS X. Esta es una diferencia clave con Windows.
Lo extraño para mí es que tengo el mismo problema, pero estoy ejecutando el sistema operativo exclusivo de Microsoft en mi MacBook Pro 15 "2008. Obtengo esta desaceleración del tráfico tanto en wifi como en ethernet. ¿Hay alguna solución? ¿Este hardware está relacionado? Gracias

Respuestas (17)

Cuando sus conexiones comienzan a agotarse, ¿puede hacerlo arp -anen Terminal.app y ver si todavía tiene todas las direcciones MAC en la tabla ARP? como en: ¿la dirección MAC de su enrutador o el host al que intenta hacer ping?

Si lo hace (y tiene tiempo antes de que comience a funcionar nuevamente), ¿puede vaciar la tabla arp ( sudo arp -ad) y luego ver si la dirección MAC de su enrutador aparece nuevamente en la tabla ARP?

Además, intente ejecutar un ping a la dirección IP LAN de su enrutador en una sesión de Terminal, y tal vez un ping a la dirección IP WAN de su enrutador en otra mientras está en Skype. Vea si todos ellos comienzan a agotar el tiempo de espera o solo uno de ellos. Una herramienta más que encuentro útil es mtr: es posible que deba obtener la fuente y compilarla usted mismo o usar fink / macports u otro administrador de paquetes. Cuando lo obtenga, simplemente ejecútelo a un destino en algún lugar de Internet y le mostrará qué salto deja de responder.

Cómo instalar software desde fuentes (como mtr) Requiere que se instale Xcode :

  • descargar el archivo fuente (normalmente .tar.gz o .tar.bz2)
  • descomprima el archivo descargado (por ejemplo, en Terminal.app run gzip -dc filename.tar.gz | tar -xvf -, que normalmente creará un nuevo directorio en el directorio actual y colocará el contenido del archivo allí)
  • navegar a la carpeta obtenida en la terminal
  • ejecutar ./configure --prefix=/usr/local(tenga en cuenta que me gusta instalar el software desde la fuente /usr/localpara mantenerlo alejado de los archivos binarios instalados como parte del sistema; la --prefix=/usr/localopción de configuración hará exactamente eso)
  • corrermake
  • corrersudo make install
  • ¡hecho!
Hecho esto, en breve editará la pregunta con los resultados.
Cuando hago 'arp -an' después de eliminar la tabla, no aparece el enrutador hasta que se vuelve a conectar.
→ mike: mtres una excelente herramienta. Desafortunadamente aquí el problema está mucho menos lejos. El problema parece estar entre MacOS X y 192.168.1.1. No hay necesidad de cazar hacia el horizonte de Internet ☺.
Este comando realmente me ayudó.

¿Podría primero comprobar que realmente está utilizando la interfaz de red? Debería:

ifconfig -a

¿Podría mirar el resultado de los siguientes comandos (si en0 es el nombre de la interfaz de red de su tarjeta Ethernet):

netstat -I en0

Para ayudar a localizar el problema, ¿podría crear una ubicación específica con solo su tarjeta Ethernet activada y, si es posible, solo usando IPv4 o IPv6, pero no ambos?Ubicación con solo Ethernet activado

¿Podría ejecutar el siguiente extracto de posibles errores de hardware o controlador?

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

(no se asuste, puede encontrar mucha información sobre los canales Wi-Fi).

El siguiente mensaje exhibido por su netstat:

44620 embryonic connections dropped

significa que usted es en realidad el objetivo de una inundación de sincronización tcp tonta (que es un ataque de denegación de servicio (DOS)).

Cuando tu:

ping 192.168.1.1

se ahoga por 6s, podrías ejecutar:

netstat -m
Cuando 192.168.1.1 ahoga 'netstat -m' no muestra nada fuera de lo común. Por cierto, parece que grep no puede encontrar '/var/log/kernel.log'. Estoy editando la pregunta con los resultados de 'netstat -I en1' (estoy usando en1 en este momento, que es mi aeropuerto, en0 está inactivo). ¿Cuál podría ser el motivo del ataque DOS?
→ Miguel: para simplificar tu análisis de tu problema, haz una nueva red conf. con solo la interfaz Ethernet activada. Luego manténgase dentro de una ventana a ping 192.168.1.1(que no hará ninguna solicitud de DNS).
→ Miguel: podrías haber sido sin querer el autor de tu ataque DOS ☹, pero esto aún está por confirmar. Sospecho que un bucle de red causado por una Automaticconfiguración.
→ Miguel: ¿podrías facilitarnos un ifconfig -a?
Editaré la pregunta ahora con los resultados.
Hice una nueva configuración de red solo con ethernet y haré ping a '192.168.1.1' durante las próximas 24 horas para ver qué sucede.
→ Miguel: ¿podrías proporcionarnos una ifconfig -aconfiguración de solo Ethernet? Si tiene la suerte de poder producir su problema en Ethernet, entonces es mucho más fácil enfocarse en esta forma más simple del problema (Ethernet es 1 dimensión donde Wireless es 3 ☺).
Esto resolvió mi problema, saqué la Automaticubicación en Preferencias de red, creé una nueva ubicación para Casa y Trabajo y eso parece haber detenido los tiempos de espera de bloqueo.

He tenido este problema durante mucho tiempo (comenzando después de una actualización a Mavericks) y, después de meses de investigación, creo que finalmente encontré una solución.

En primer lugar, hay bastantes personas con el mismo problema en los foros de Apple:

Entonces, este es un problema conocido y realmente no sé por qué Apple aún no ha proporcionado una solución para esto. En los hilos enumerados anteriormente, hay muchas sugerencias para solucionar este problema, pero la mayoría no funcionó. Algunos solucionan el problema temporalmente:

  • Desconectar y volver a conectar la red
  • El viejo amigo: reiniciar
  • Elimine la carpeta que contiene la configuración de red:sudo rm -rf /Library/Preferences/SystemConfiguration

Después de estas medidas, la conexión de red se siente mucho mejor y no experimento caídas durante varias horas o, a veces, incluso días. Pero los problemas siempre vuelven.

Esta pregunta y los indicios de que el problema podría estar relacionado con ARP me llevaron a investigar más y encontré esta página , que describe el error en detalle y también contiene un parche, que cito aquí:

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 el enlace proporcionado para obtener una explicación detallada de la solución, que se supone que Apple incluirá en una futura actualización del sistema operativo para Yosemite. Deshabilita las solicitudes ARP de unidifusión, lo que causa confusión con algunos equipos de red como el enrutador de su hogar.

Después de aplicar la solución y reiniciar, se debe verificar si

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

regresa net.link.ether.inet.arp_unicast_lim: 0_ Si el número no es igual a cero, la solución no se aplicó correctamente.

Luego, encontré otro hilo en las comunidades de Apple que contiene la misma solución: Mavericks y ARP fallido que causan caídas en la red. Bueno, después de saber cuál es el problema, encontrar la solución correcta es mucho más fácil.

Primero, veo Dropbox ejecutándose en su barra de menú; ¿Ya lo has deshabilitado?

En segundo lugar, intente eliminar cualquier otro elemento de inicio/inicio de sesión. Pase a ver:

Acceso:

  1. ~/Biblioteca/LaunchAgents/
  2. ~/Biblioteca/LaunchDaemons/
  3. Preferencias del sistema > Usuarios y grupos > Elementos de inicio de sesión

Puesta en marcha:

  1. /Biblioteca/LaunchAgents/
  2. /Biblioteca/LaunchDaemons/
  3. /Biblioteca/Elementos de inicio/
  4. /Library/Preferences/com.apple.loginitems.plist (rara vez existe)
No he intentado deshabilitar Dropbox, ¿sería útil? Y también, ¿podría explicar el motivo de la eliminación de esos elementos? ¡Gracias!
Desea aislar si el problema es con OS X o con una pieza de software que se agregó después de la instalación inicial. Cosas como Dropbox que establece conexiones de red tan pronto como se carga la cuenta de usuario, o el software antivirus que generalmente se ejecuta en todas las cuentas de usuario pueden estar reservando un puerto o contribuyendo de otra manera al problema.
Ok, haré esto y publicaré aquí los resultados mañana.
→ Miguel: Dropbox no puede ser tu problema. Dropbox simplemente está haciendo 443/tcp como cualquier otra navegación web. Pero en caso de que quisiera hacer un rastreo de red (Wireshark o tcpdump), detener Dropbox eliminará una gran cantidad de tráfico tcp. Por lo tanto, esto le ayudará a "ver" cualquier mal comportamiento.
Estas son algunas buenas conjeturas para la solución de problemas, pero si tuviera que explicar cómo y por qué sintió que estos elementos afectarían la continuidad de la red, la respuesta sería más útil para el OP, pero también enseñaría a las personas en situaciones similares por qué sugirió esto como opuesto a algo a descartar.
@Miguel, algunas conjeturas más. 1. ¿Ha contactado a su ISP para ver si pueden verificar la calidad de la línea? 2. ¿Qué tal configurar una cuenta de usuario de prueba para ver si el problema se mueve? Una tercera sugerencia es verificar su sistema, cosas como verificación de permisos, diagnósticos de la máquina. 4. ¿Es posible que pueda intercambiar componentes? Haga funcionar su computadora en la ubicación de un amigo, tome prestado el enrutador de su amigo, ah, y elimine todos los demás equipos de red de su sistema.
@DavidDelMonte, la computadora funciona bien en otras ubicaciones. Intentaré configurar una nueva cuenta de usuario. Mi ISP me dice que todo está perfecto y que otras máquinas en mi red no tienen ningún problema. Reparé permisos y todo perfecto, pero no puedo intercambiar componentes.

Aquí hay una gran cantidad de información sobre la resolución de problemas y el diagnóstico final, pero a veces, cuando se solucionan los problemas, es divertido volver a lo básico y cuestionar algunas suposiciones.

Como mencioné en un comentario, esto se parece mucho a un enrutador QOS que se activa debido a que su máquina excedió temporalmente un límite de ancho de banda o tasa de paquetes.

¿Qué pasa si está haciendo diferentes patrones, volúmenes y cantidades de tráfico de red mientras está en OS X en comparación con Windows y esa es la causa real, no los controladores de hardware o el software?

Esperaría que ejecutar OS X se correlacione con sus observaciones, pero ¿y si no es la causa de las pausas temporales de la red?

¿Ha intentado investigar qué pasa si su proveedor de red implementa filtros QOS y cambios de enrutamiento? ¿Ha considerado canalizar todo el tráfico a otra computadora (ssh o VPN) para poder descartar filtros triviales? (Si el proveedor está realizando una inspección profunda de paquetes o un destino y una limitación de velocidad real, es posible que no pueda escapar de estos breves tiempos de espera).

Espero que pueda encontrar una respuesta al observar los detalles de la red (y todos aprenderemos algo al explorar esas opciones), pero asegúrese de considerar también que sus herramientas de medición y el tráfico agregado para hacer ping/poker en las cosas podrían estar afectando los conteos de tráfico y haciendo que sea más probable que Skype se caiga para usted. Los enrutadores que configuro están programados para descartar el tráfico ICMP antes que el resto del tráfico, ya que cuando la capacidad es escasa, prefiero que falle el ping y pasen otros paquetes. Es posible que su ISP y su proveedor de red hayan configurado las cosas de manera similar.

Ya veo... pero nada cambió en mi actividad de networking en los últimos 5 años. Este problema comenzó hace aproximadamente un mes y no puedo encontrar ninguna correlación, excepto que fue hace aproximadamente un mes cuando 2 colegas se mudaron. Pero realicé pruebas de ping en sus máquinas y no experimentan este problema. No conozco ningún filtro QOS, pero intentaré averiguarlo.
Skype recibe una llamada casi las 24 horas del día, los 7 días de la semana en mi máquina... Desactivaré todos los pings, etc. hoy para ver si algo cambia la próxima vez que se caiga la conexión (porque todavía puedo saber si se cae escuchando el audio recibo de la llamada de Skype)

Además de todas las cosas aquí, es posible que desee asegurarse de que Auto Proxy Discovery no esté activado (así como Automatic Proxy Configuration). Eso tiende a causar más problemas que no y, a menudo, no es necesario.

Preferencias del Sistema

Gracias por el consejo, aunque ya estaban apagados :(

Con toda la excelente información de diagnóstico en esta pregunta, ha reducido enormemente las posibilidades.

Para empezar, sus pings a 192.168.1.1 aíslan en gran medida el problema a su enrutador, computadora o LAN. Esto no es un problema con DNS o su ISP.

Estoy muy preocupado por los resultados de sus pruebas de ping a 192.168.1.1. ¿Hiciste algo raro al configurarlos?

Por ejemplo, tiene pings exitosos con números de secuencia ICMP de 24267, 24268 y 24269, luego 3 tiempos de espera, luego éxito nuevamente con ICMP 24273. Entonces, los números de los éxitos parecen correctos. Sin embargo, los números de los tiempos de espera son completamente diferentes. Esperaría ver tiempos de espera de solicitud de ICMP 24270, 24271 y 24272, pero en cambio los tiempos de espera informan ICMP 89806, 89807 y 89808. Nunca había visto eso antes, por lo que me sugiere que tiene una pila de red rota en eso. computadora. Quizás demasiadas extensiones. ¿Hay alguna posibilidad de que tengas Netgear Genie instalado? ¿O tal vez un software VPN?

En cualquier caso, diría que es hora de comenzar a deshabilitar las "mejoras" para ver si puede encontrar un culpable instalado en la computadora.

Editar

Vale, misterio resuelto. El número de secuencia ICMP es un campo de 16 bits. Si se trata como un entero sin signo, eso significa que tiene un valor máximo de 65 535 y luego vuelve a cero. Entonces, si el programa de ping local mantiene un contador de enteros de 32 bits (que probablemente lo haría de forma predeterminada), podría informar un número entero de 32 bits para los paquetes faltantes. Sin embargo, al leer las respuestas, la respuesta necesariamente solo tendrá los últimos 16 bits del contador. Entonces, la respuesta al número de secuencia 89805 será 89505 y 0xFFFF, que es 24269.

Hola. No hice nada extraño... es solo un 'sudo ping 192.168.1.1'... Veo lo que dices sobre los números de secuencia ICMP... No tengo idea de por qué podría ser... tal vez el ping estuvo funcionando durante demasiado tiempo? (ha estado funcionando durante días)... Ni idea. Además, la configuración de mi red es muy simple y he estado usando la misma configuración durante años sin ningún problema.
Software que siempre se ejecuta en segundo plano y que podría tener algo que ver con esto: Little Snitch, Dropbox, Skype y todo lo relacionado con OS X... pero nada nuevo, y el problema comenzó hace aproximadamente un mes. Una cosa que sospecho es que fue hace aproximadamente un mes cuando 2 nuevos compañeros de cuarto se mudaron. Realicé pruebas de ping en sus computadoras y, sin embargo, no tienen este problema.
@Miguel, definitivamente elimine Little Snitch ya que ese es exactamente el tipo de software que podría estar creando este problema. Si no tiene una configuración complicada, diría que la desinstale por completo e incluso vacíe la papelera para asegurarse de que se haya ido y reinicie y vea si eso soluciona el problema.
Ok, lo desinstalaré por completo y veré qué sucede (pero lo he estado usando durante años sin ningún problema).
Gracioso... 24269 en binario es 0000 0101 1110 1100 1101. 89806 en binario es 0001 0101 1110 1100 1110. Sin embargo, si tomamos 24269 y cambiamos el bit 16, obtenemos 0001 0101 1110 1100 1101 = 89805. parece un entero con signo o sin signo, por lo que es una presentación puramente numérica. Puede ser que el dispositivo al que Miguel está haciendo ping use un número entero sin firmar en lugar de firmado (o al revés)...

Sé que este es un tema antiguo.

Pero gracias a todos por esta solución de problemas. Todos los pasos me ayudaron a solucionar un problema en el que podía hacer ping a los hosts pero no conectarme a ellos a través de telnet.

La solución fue bastante simple (luego) eliminó todas las cosas innecesarias de aquí (como mencionó zac)

Acceso:

~/Library/LaunchAgents/ ~/Library/LaunchDaemons/ Preferencias del sistema > Usuarios y grupos > Elementos de inicio de sesión

Puesta en marcha:

/Library/LaunchAgents/ /Library/LaunchDaemons/ /Library/StartupItems/ /Library/Preferences/com.apple.loginitems.plist (rara vez existe)

De nuevo, gracias a todos

Curioso problema teniendo en cuenta que persiste de ethernet. Tuve un problema similar, pero descubrí que la interferencia WiFi de otras redes era el problema. Cambiar a una banda de 5 GHz solucionó mi problema, lo cual supongo que vale la pena intentarlo.

Antes de cambiar el canal de la red porque cree que tiene un problema de interferencia, simplemente diagnostíquelo claramente. Esto es bastante fácil: usa istumbler.net . Mirarás la verdad directamente a los ojos ☺.

¿Alguna sugerencia de /var/log/system.log?

¿Cómo se ve netstat -s?

Mi corazonada dice que elimine /Library/Preferences/SystemConfiguration y vuelva a agregar las interfaces de red manualmente.

Sin embargo, parece que ya has probado muchas cosas.

Hola Miguel, agregando más vudú después de ver tus capturas de pantalla. ¿podría probar estas tres cosas: 1: deshabilitar bluetooth, 2: probar las interfaces de red 1 por 1? 3: solo para confirmar, está utilizando controladores de red estándar, ¿verdad?
El system.log es enorme... Busqué palabras específicas pero no pude encontrar nada relevante :(
Editaré la pregunta agregando los datos que me dio netstat -s.
Ya eliminé toda la configuración de red. y volví a agregar todo manualmente pero sin suerte. Bluetooth siempre ha estado apagado. Estoy usando controladores de red de stock. Todas las interfaces de red dan exactamente los mismos resultados: una pérdida momentánea de conexión de vez en cuando :(
El error del paquete icmp e ip me preocupa. por separado, instale una copia nueva de OSX y arranque desde ella a través de USB. Esto aislará su instalación de OSX. si una copia nueva sigue teniendo errores, entonces tenemos un error de hardware; quién sabe, puede ser que solo los controladores OSX lo activen. Muestre que el problema aparece en una instalación nueva, y Apple debería solucionarlo por usted
Haré esto si puedo tener algo de tiempo libre, tengo mucho trabajo por hacer :\

¿Se parece a esto?

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

Acabo de publicar esto para Mavericks. ¿Pensamientos?

Si bien este enlace puede responder la pregunta, es mejor incluir las partes esenciales de la respuesta aquí y proporcionar el enlace como referencia. Las respuestas de solo enlace pueden dejar de ser válidas si la página enlazada cambia.
Intentaré echar un vistazo a la solución en el enlace para ver si también me ayuda. Volveré a publicar.

Mac OSX Sugerencias http://hints.macworld.com/article.php?story=20080605143917233 sobre conexiones interrumpidas debido a que las búsquedas de DNS fallan a la espera de la identificación DCHP de un enrutador.

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

Lo más probable es que el DNS y/o una configuración de aceleración en la configuración de su módem y omitir ese DNS ayuden a resolver su problema.

Eso no causaría este problema. ping hace una búsqueda de DNS una vez (google.com -> 173.194.34.196 en este caso), luego usa la dirección IP a partir de ese momento.
Hará esto e informará.
→ Blip: este no es un problema relacionado con el DNS. El ping hacia el enrutador con una dirección IP no genera ningún paquete UDP, solo un eco tonto de ICMP.

Esto huele a que otro dispositivo en su red está tratando de usar la misma IP que usted, o algún problema con DHCP.

¿Podrías ver si aún puedes reproducirlo después de asignarte una IP estática?

Vaya a Preferencias de red, elija su interfaz Ethernet, avanzada, TCP/IP

Cambie el menú desplegable "Configurar IPv4" a "Manualmente"

Dirección IPv4: 192.168.1.150 (algo único, no lo que DHCP le había asignado antes) Máscara de subred: 255.255.255.0 Enrutador: 192.168.1.1

Ahorrar

A continuación, intente reproducir el problema de nuevo. Al hacer esta prueba, asegúrese de que su Wi-Fi esté apagado para que solo su Ethernet esté en uso. Esto ayudará a reducirlo.

Si aún tiene el problema, debe descargar Wireshark ( http://www.wireshark.org/ ), iniciar una captura, reproducir el problema, guardar el volcado y dejarnos echar un vistazo.

Además, ¿qué enrutador/AP estás usando?

Dos cosas para verificar que se correlacionan con que esto sea causado por un aumento en el tráfico LAN debido a nuevos compañeros de habitación.

  1. ¿Hay configuraciones de QoS (Calidad de servicio) en el enrutador y, de ser así, cómo se configuran? El tráfico de Skype se priorizaría y si la WAN se satura, el enrutador podría responder cerrando temporalmente las conexiones de menor prioridad.
  2. ¿La CPU del enrutador simplemente se está sobrecargando? Cuando actualicé el servicio de cable de 1 Gbs DSL a 5 Gbs, descubrí que mi enrutador simplemente no podía mantenerse al día con el aumento del tráfico y tuve que comprar uno nuevo. Investigue el rendimiento de su enrutador y vea si esto podría ser un problema. La mayoría de los enrutadores tienen revisiones de rendimiento detalladas disponibles en Internet; verifique y vea cómo se clasifica su enrutador en comparación con la capacidad de su servicio de Internet.

Hola chicos, estaba teniendo exactamente el mismo problema, pero acabo de desconectar los auriculares que estaba usando y he estado hablando con mi amigo durante los primeros 10 minutos y todavía no ha bajado, cuando antes bajaba a los 20 segundos.

El cable de mis auriculares se rompió, por lo que puede haber causado el problema, pero no sé mucho sobre la dirección IP y las cosas de ping, y esto pareció ayudarme. Si lo intentas y no funciona no me culpes, porque solucionó mi problema.

La solución fue bastante simple (luego) eliminó todas las cosas innecesarias de aquí (como mencionó zac)

Acceso:

~/Library/LaunchAgents/ ~/Library/LaunchDaemons/ Preferencias del sistema > Usuarios y grupos > Elementos de inicio de sesión

Puesta en marcha:

/Library/LaunchAgents/ /Library/LaunchDaemons/ /Library/StartupItems/ >/Library/Preferences/com.apple.loginitems.plist (rara vez existe)

Sé que este es un hilo antiguo, pero hacer esto solucionó el problema que tenía. Mi Internet a veces se desconectaba y los ping caían todo el tiempo. Lo que solucionaría mi problema es apagar wi-fi o ethernet (lo que estaba usando), luego volver a habilitarlo. Por supuesto, esto solo solucionaría temporalmente el problema. Era extraño porque cada vez que mi mac pro 4.1 tenía este problema, mi computadora portátil mac también perdía pings. Era casi como si mi Mac Pro derribara mi red.

¡Intenté tantas cosas! reemplazando el modem, router, llamado isp, compre usb a ethernet. ¡ninguna de esas cosas funcionó, hasta que probé esto!

¡Hice lo mencionado anteriormente y finalmente solucionó el problema!

Tuve un problema similar y en mi caso parece ser causado por Tunnelblick, incluso cuando la VPN no estaba conectada. Lo desinstalé (con el desinstalador, no solo arrastrándolo a la Papelera) y el problema desapareció.

Intrigante problema de conexión en OS X
RespuestasAquíPolítica de privacidad1y, 0v