Entonces, un problema reciente con mi Macbook Pro con M1 Pro ejecutando macOS Ventura beta es que sigue perdiendo su conexión a Internet exactamente cada 10 segundos.
Independientemente de si estoy usando ethernet, Wi-Fi del trabajo o de casa, o incluso el hotspot de mi teléfono celular.
Por ejemplo, resultados de ping:
PING google.com (142.251.32.206): 56 bytes de datos
64 bytes desde 142.251.32.206: icmp_seq=0 ttl=52 tiempo=9.467 ms
64 bytes desde 142.251.32.206: icmp_seq=1 ttl=52 tiempo=11.747 ms
ping: sendto: No hay ruta al host
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 2
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 3
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 4
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 5
Tiempo de espera de solicitud para icmp_seq 6
64 bytes desde 142.251.32.206: icmp_seq=7 ttl=52 tiempo=9.934 ms
64 bytes desde 142.251.32.206: icmp_seq=8 ttl=52 tiempo=10.050 ms
64 bytes desde 142.251.32.206: icmp_seq=9 ttl=52 tiempo=13.127 ms
64 bytes desde 142.251.32.206: icmp_seq=10 ttl=52 tiempo=11.709 ms
64 bytes desde 142.251.32.206: icmp_seq=11 ttl=52 tiempo=10.346 ms
ping: sendto: No hay ruta al host
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 12
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 13
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 14
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 15
Tiempo de espera de solicitud para icmp_seq 16
64 bytes desde 142.251.32.206: icmp_seq=17 ttl=52 tiempo=11.902 ms
64 bytes desde 142.251.32.206: icmp_seq=18 ttl=52 tiempo=10.025 ms
64 bytes desde 142.251.32.206: icmp_seq=19 ttl=52 tiempo=10.130 ms
64 bytes desde 142.251.32.206: icmp_seq=20 ttl=52 tiempo=10.546 ms
64 bytes desde 142.251.32.206: icmp_seq=21 ttl=52 tiempo=9.967 ms
ping: sendto: No hay ruta al host
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 22
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 23
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 24
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 25
ping: sendto: No hay ruta al host
Tiempo de espera de solicitud para icmp_seq 26
Tiempo de espera de solicitud para icmp_seq 27
64 bytes desde 142.251.32.206: icmp_seq=28 ttl=52 tiempo=9.903 ms
64 bytes desde 142.251.32.206: icmp_seq=29 ttl=52 tiempo=9.885 ms
64 bytes desde 142.251.32.206: icmp_seq=30 ttl=52 tiempo=9.557 ms
64 bytes desde 142.251.32.206: icmp_seq=31 ttl=52 tiempo=9.982 ms
He intentado:
- apagar y encender wifi
- reiniciar
- renovar el contrato de arrendamiento DHCP
- eliminar el servicio de wifi o ethernet en Configuración -> Red y volver a agregarlo
- usar diferentes servidores DNS como 1.1.1.1 en lugar del predeterminado
El hecho de que ocurra tanto en wifi como en ethernet, ya sea en el trabajo o en casa, sugiere que no es un problema del enrutador.
¿Alguna idea?
Edición 1: Según la sugerencia de Allan en los comentarios, reinicié en modo de Recuperación y usé la Terminal allí para hacer ping a google de nuevo, y no hay interrupciones cada 10 segundos. Pero al iniciar sesión de nuevo en modo no de Recuperación, el problema persiste ;_;
1 votos
En lugar de enviar una solicitud a algo fuera de su red (como Google), comience enviándola a algo dentro de su red, como el enrutador u otro dispositivo. Esto comenzará a reducir el problema.
0 votos
@Allan Mismo problema dentro de la red también, se cae cada 10 segundos.
1 votos
¿Qué pingueaste? ¿Cuáles fueron los resultados? ¿Puedes publicar como hiciste con los resultados del ping de Google?
0 votos
No puedo publicar los resultados con mi dirección IP de trabajo listada (mis IPs externa e interna son las mismas), pero hice ping a una computadora vecina que está en la misma subred (es decir, hice ping a
a.b.c.d
desdea.b.c.e
). También he hecho esto en casa, con 192.168.1.x pero no tengo el texto para copiar/pegar. Mismo resultado, con "No route to host" y "Request timeout" exactamente cada 10 segundos.1 votos
Las IPs en el trabajo son similares a las de casa en el sentido de que son direcciones privadas y utilizadas por muchas otras organizaciones. Aún puedes ofuscar si es necesario. ¿Tienes software de VPN, entradas personalizadas de DNS? ¿Tienes WiFi y Ethernet activos al mismo tiempo? Si es así, desactiva y enfócate primero en Ethernet.
0 votos
He eliminado las entradas de DNS personalizadas que había intentado (1.1.1.1) por lo que no hay DNS personalizado; he desinstalado mi software VPN de trabajo (ya no aparece en Configuración -> Red -> Filtros); y he probado wifi y ethernet por separado eliminando el otro servicio (haciendo clic con Ctrl en la red en Configuración -> Red). El problema de desconexión cada 10 segundos persiste tanto si estoy solo en wifi como en ethernet.
1 votos
Arranque en Modo Seguro o de Recuperación. Si es de Recuperación, una vez allí, abra la Terminal (menú de Utilidades) e intente hacer ping nuevamente.
0 votos
Interesante: en el Terminal del modo de recuperación, no veo caídas en la conexión Ethernet al hacer ping a una computadora local o a algo fuera de la red. ¡Buena idea!
1 votos
Esto significa que una aplicación o kext de terceros es el responsable aquí. Es posible que quieras hacer una copia de seguridad completa, luego una instalación limpia (en un disco externo por ahora) e instalar las cosas una por una. Algo se instaló que está interfiriendo con tu pila de red.
0 votos
@Allan ¡Gracias por tu pista sobre el modo de recuperación! Resulta que es el servicio Cisco AMP for Endpoints MaLwARE ProtECTioN de mi trabajo, que también agrega un filtro de contenido a Configuración -> Red -> Filtros. ¡Desactivé ese filtro también, cerré Amp y la red ya no se desconecta cada 10 segundos! Resulta que en realidad es un error con los filtros de contenido en la última versión de Ventura: macrumors.com/2023/05/02/… ¿Cómo marco esto como resuelto si no hay "Respuestas"? ¡Siéntete libre de publicar tu comentario sobre el modo de recuperación como respuesta y lo aceptaré!
1 votos
La recuperación era solo el diagnóstico, ya que carga una versión completamente limpia de macOS que eliminaría positivamente cualquier "contaminante" de terceros. Adelante y responde tú mismo, luego avísame aquí para poder votar positivamente por ti. ¡Después de todo, tú hiciste el trabajo de investigación y encontraste la respuesta!