Recientemente he tenido este problema con mi conexión a Internet en mi MacBook Pro a 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.
Sucede tanto por Wi-Fi como por cable Ethernet , y solo le sucede a mi máquina cuando ejecuta OS X (no ocurrirá cuando ejecute Windows 7 en la misma máquina o en cualquier otra máquina / dispositivo). Hace que Skype cuelgue 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 dejan caer 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: el MAC de 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 esquina superior izquierdaping 85.61.155.224en la parte inferior izquierdaping google.comen la parte inferior derecha- Los comandos
arp -anyarp -adejecutados.
Cuando ejecuté el arp -adcomando en un momento en que se perdió la conexión, la lista no mostraba 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 el conocimiento suficiente para seguir las instrucciones de Mike sobre cómo obtener y compilar la fuente del mtrcomando.
Así es como se ven las cosas cuando es peor:
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 ningún 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.
- Enciende y apaga AirPort, diferentes cables Ethernet.
- Permisos de reparación.
- Restablecer la PRAM.
- Borre todas las 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 las ideas sobre cómo abordar este problema.
Respuestas:
Cuando sus conexiones comienzan a agotar el tiempo de espera, ¿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 que está intentando hacer ping?Si lo hace (y tiene el 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 comienzan a expirar o solo uno de ellos. Una herramienta más que me parece útil es
mtr: puede que necesite 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 :
gzip -dc filename.tar.gz | tar -xvf -, que generalmente creará un nuevo directorio en el directorio actual y colocará el contenido del archivo allí)./configure --prefix=/usr/local(tenga en cuenta que me gusta instalar el software desde el origen/usr/localpara mantenerlo alejado de los archivos binarios instalados como parte del sistema; la--prefix=/usr/localopción de configuración hará exactamente eso)makesudo make installfuente
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 es necesario cazar hacia el horizonte de Internet ☺.¿Podría primero verificar que realmente está utilizando la interfaz de red?
¿Podría mirar la salida de los siguientes comandos (si en0 es el nombre de la interfaz de red de su tarjeta Ethernet):
Para ayudar a localizar el problema, ¿podría hacer una ubicación específica con solo su tarjeta Ethernet activada y, si es posible, solo usando IPv4 o IPv6 pero no ambos:
¿Podría ejecutar el siguiente extracto de posibles errores de hardware o controlador:
(no se asuste, puede encontrar mucha información sobre los canales de Wi-Fi).
El siguiente mensaje exhibido por su netstat:
significa que en realidad eres el objetivo de una tonta inundación de sincronización TCP (que es un ataque de denegación de servicio (DOS)).
Cuando tu:
se ahoga por 6s, ¿podrías correr:
fuente
ping 192.168.1.1(que no hará ninguna solicitud de DNS).Automaticconfiguración.ifconfig -a?Automaticubicación en Preferencias de red, creé una nueva ubicación para el hogar y el trabajo y 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:
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 esto, pero la mayoría de ellas no funcionó. Algunos solucionan el problema temporalmente:
sudo rm -rf /Library/Preferences/SystemConfigurationDespués de estas medidas, la conexión de red se siente mucho mejor y no experimento caídas durante varias horas o incluso días. Pero los problemas siempre vuelven.
Esta pregunta y las sugerencias de que el problema podría estar relacionado con ARP me llevaron a comenzar más investigaciones y encontré esta página , que describe el error en detalle y también contiene un parche, que cito aquí:
Consulte el enlace proporcionado para obtener una explicación detallada de la solución, que se supone que se incluirá en una futura actualización del sistema operativo para Yosemite por parte de Apple. Deshabilita las solicitudes de 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 corrección y reiniciar, se debe verificar si
vuelve
net.link.ether.inet.arp_unicast_lim: 0. Si el número no es igual a cero, la corrección no se aplicó correctamente.Después, encontré otro hilo en las comunidades de Apple que contiene la misma solución: ¡ Mavericks y ARP fallido que causan caídas de la red! Bueno, después de saber cuál es el problema, encontrar la solución correcta es mucho más fácil.
fuente
Primero, veo Dropbox ejecutándose en su barra de menú; ¿ya has desactivado eso?
En segundo lugar, intente eliminar cualquier otro elemento de inicio / inicio de sesión. Pase a ver:
Iniciar sesión:
Puesta en marcha:
fuente
Aquí hay una gran cantidad de información sobre la resolución de problemas y el diagnóstico, pero a veces, cuando se trata de solucionar problemas, es divertido volver a lo básico y cuestionar algunos supuestos.
Como mencioné en un comentario, esto se parece mucho a un enrutador QOS que se activa debido a que su máquina excede temporalmente el ancho de banda o el límite de velocidad de paquetes.
¿Qué sucede si está haciendo diferentes patrones, volúmenes y cantidades de tráfico de red mientras está en OS X en lugar de Windows y esa es la causa real, no los controladores de hardware o el software?
Esperaría que OS X esté correlacionado con sus observaciones, pero ¿y si no es la causa de las pausas temporales de la red?
¿Ha intentado investigar qué sucede si su proveedor de red implementa filtros de calidad de servicio y cambios de ruta? ¿Ha considerado hacer un túnel para todo el tráfico a otra computadora (ssh o VPN) para que pueda descartar filtros triviales? (Si el proveedor está realizando una inspección profunda de paquetes o un límite de destino y velocidad real, es posible que no pueda escapar de estos cortos tiempos de espera).
Espero que pueda encontrar una respuesta al ver 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 / pokear a las cosas podrían afectará el conteo de tráfico y hará que sea más probable que Skype se caiga por ti. Los enrutadores que configuré están programados para eliminar el tráfico ICMP antes que el resto del tráfico, ya que cuando la capacidad se reduce, prefiero que el ping falle y que pasen otros paquetes. Su ISP y su proveedor de red podrían haber configurado las cosas de manera similar.
fuente
Además de todas las cosas aquí, es posible que desee asegurarse de que Auto Proxy Discovery no esté activado (así como la Configuración automática de proxy). Eso tiende a causar más problemas que a menudo y a menudo no es necesario.
fuente
Con toda la gran información de diagnóstico en esta pregunta, ha reducido las posibilidades enormemente.
Para comenzar, sus pings a 192.168.1.1 aíslan en gran medida el problema en su enrutador, computadora o LAN. Esto no es un problema con DNS o su ISP.
Estoy más perturbado 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. Por lo tanto, los números de los éxitos parecen correctos. Sin embargo, los números de los tiempos de espera son completamente diferentes. Esperaría ver los tiempos de espera de solicitud de ICMP 24270, 24271 y 24272, pero en su lugar, los tiempos de espera informan ICMP 89806, 89807 y 89808. Nunca he visto eso antes y, por lo tanto, me sugiere que tiene una pila de red rota en eso computadora. Quizás una demasiadas extensiones. ¿Alguna posibilidad de que haya instalado Netgear Genie? ¿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
OK, 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 se ajusta a cero. Entonces, si el programa de ping local mantiene un contador de enteros de 32 bits (que probablemente lo haría de manera predeterminada), podría informar un número entero de 32 bits para los paquetes faltantes. Sin embargo, al leer las respuestas, la respuesta solo tendrá necesariamente los últimos 16 bits del contador. Entonces, la respuesta al número de secuencia 89805 será 89505 y 0xFFFF, que es 24269.
fuente
Sé que este es un viejo tema.
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 se mencionó zac)
Iniciar sesión:
~ / 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
fuente
Curioso problema considerando que persiste de ethernet. Tuve un problema similar, pero el problema fue la interferencia WiFi de otras redes. Cambiar a una banda de 5 GHz solucionó mi problema, lo que es una suposición, vale la pena intentarlo.
fuente
¿Alguna pista de /var/log/system.log?
¿Cómo se ve netstat -s?
Mi presentimiento dice eliminar / Library / Preferences / SystemConfiguration y volver a agregar las interfaces de red manualmente.
Parece que ya has intentado muchas cosas.
fuente
¿Se parece a esto?
https://discussions.apple.com/thread/5483424?tstart=0
Acabo de publicar esto para Mavericks. Pensamientos?
fuente
Mac OSX sugiere http://hints.macworld.com/article.php?story=20080605143917233 en conexiones caídas porque las búsquedas de DNS fallan en espera de la identificación DCHP de un enrutador.
Es muy probable que el DNS y / o una configuración de aceleración en la configuración de su módem y eludir ese DNS lo ayude a resolver su problema.
fuente
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ía ver si aún puede reproducirlo después de asignarse una IP estática?
Pase 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
Salvar
Luego intente reproducir el problema nuevamente. 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 todavía tiene el problema, debe descargar Wireshark ( http://www.wireshark.org/ ) para iniciar una captura, reproducir el problema, guardar el volcado y dejarnos echar un vistazo.
Además, ¿qué enrutador / AP está utilizando?
fuente
Dos cosas para verificar que se correlacionan con que esto sea causado por el aumento del tráfico LAN debido a nuevos compañeros de cuarto.
fuente
Hola chicos, estaba teniendo el mismo problema exacto, pero simplemente desconecté los auriculares que estaba usando y he estado hablando con mi amigo durante los primeros 10 minutos y todavía no se ha caído, cuando antes se había caído a los 20 segundos.
El cable de mis auriculares se rasgó, por lo que puede haber estado causando el problema, pero no sé mucho sobre la dirección IP y el ping, y esto pareció ayudarme. Si lo intentas y no funciona, no me culpes, porque solucionó mi problema.
fuente
Sé que este es un hilo viejo, pero al hacerlo solucionó el problema que tenía. Mi internet a veces se desconectaba y los ping se caían todo el tiempo. Lo que solucionaría mi problema es apagar wi-fi o ethernet (lo que estaba usando) y luego volver a habilitarlo. Por supuesto, esto solo solucionaría temporalmente el problema. Fue extraño porque cada vez que mi Mac Pro 4,1 tendría este problema, mi computadora portátil Mac también perdería pings. Era casi como si mi Mac Pro derribara mi red.
¡Intenté tantas cosas! reemplazando el módem, enrutador, llamado isp, compró usb a ethernet. ¡ninguna de esas cosas funcionó, hasta que probé esto!
Hice lo que mencioné anteriormente y finalmente solucionó el problema.
fuente
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 arrastrar a la Papelera) y el problema desapareció.
fuente