Saltar al contenido principal
Descargar

Haz ping a cualquier host desde el Mac, el iPhone o el iPad

Peticiones de eco ICMP reales en Mac, iPhone y iPad, con la latencia, la pérdida y el jitter que de verdad puedes interpretar.

Por Lucas Russo, desarrollador de SSHive · Actualizado el

Descargar SSHive gratisTodas las herramientas de red
También en iPhone y iPad
Una página tarda ocho segundos en cargar, una sesión SSH se congela a mitad de un comando, una videollamada se convierte en un pase de diapositivas. Antes de tocar nada más necesitas dos cifras: cuánto tarda de verdad una ida y vuelta hasta el host, y cuántas sondas no volvieron nunca. Eso es lo que da el ping, y sigue siendo la forma más rápida de separar «el servidor está caído» de «el camino hasta el servidor está mal». Conseguir esas cifras en hardware de Apple cuesta más de lo que debería. macOS incluyó durante años Utilidad de Red con una pestaña Ping; quedó obsoleta en Big Sur, dejó de funcionar en Monterey y ya no está presente en las versiones actuales de macOS. El Terminal sigue ahí, pero es un rodeo incómodo cuando ya estás trabajando dentro de un gestor de sesiones. En iPhone y iPad directamente no hay nada que abrir: iOS no expone ninguna shell al usuario, así que ping no es un comando que puedas ejecutar, sino una capacidad que una app tiene que implementar. SSHive la implementa por su cuenta en todas las plataformas Apple en las que se publica: iPhone, iPad y la versión del Mac App Store. Todas envían peticiones echo ICMP auténticas (diez en el Mac, veinte en iPhone y iPad) e informan del tiempo de ida y vuelta de cada respuesta, del TTL con el que volvió y de cuántas no volvieron nunca. Conviene decirlo con todas las letras, porque se da por supuesto que es imposible dentro del App Sandbox de Apple. Esa suposición confunde dos cosas distintas. Un socket raw sí necesita root y el sandbox sí lo rechaza. Un socket ICMP de datagramas (socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)) no necesita ninguna de las dos: Darwin se lo entrega a procesos sin privilegios y el sandbox lo permite. Es el mismo mecanismo que usa el código de ejemplo SimplePing del propio Apple en iOS. SSHive abre ese socket directamente, así que la versión del App Store, en su sandbox, mide idas y vueltas reales y no una aproximación. Sigue disponible una sonda TCP connect contra el puerto que elijas, y es la herramienta correcta cuando el ICMP está filtrado de extremo a extremo. Es una elección deliberada en la interfaz, no una sustitución silenciosa: la tarjeta te dice qué motor produjo las cifras que estás leyendo. La herramienta es gratis en todas las plataformas. Ninguna de las herramientas de red de SSHive pasa por la comprobación de licencia Pro, y no hay anuncios ni cuenta.

Qué hace SSHive

ICMP real en todas las plataformas Apple

SSHive envía peticiones echo ICMP (diez en el Mac, veinte en iPhone y iPad) desde un socket de datagramas sin privilegios y emite cada respuesta según llega, con la forma BSD de siempre: número de secuencia, TTL y tiempo de ida y vuelta por línea, y luego un bloque de cierre con la pérdida de paquetes y min/media/máx/desviación. El mismo motor corre en la versión del Mac App Store, en iPhone y en iPad, así que las cifras son comparables entre tus dispositivos. Las respuestas se emparejan con cuatro criterios, entre ellos una cookie aleatoria de ocho bytes en la carga útil, porque un socket ICMP de datagramas recibe también copias de las respuestas de otros procesos.

Sondeo TCP connect donde el ICMP está filtrado

Muchos hosts descartan el ICMP en el borde mientras sirven el tráfico perfectamente, y un cortafuegos que se traga las peticiones echo hace que un servidor sano parezca muerto. Para esos casos, SSHive puede abrir una conexión TCP al puerto que indiques y cronometrar el handshake en su lugar. La tarjeta marca la ejecución con una etiqueta TCP, para que una comprobación de alcanzabilidad no se confunda nunca con una medida de latencia. Es además el recurso automático si el módulo ICMP nativo no se puede cargar.

Una conexión rechazada sigue contando como alcanzable

Cuando eliges deliberadamente el motor TCP, un reset es una prueba de vida: el host recibió tu SYN y lo contestó. SSHive cuenta una conexión rechazada como sonda exitosa y anota la línea como puerto cerrado en lugar de marcarla como perdida. Esa distinción te evita informar de una política de cortafuegos como si fuera una caída, cuando la máquina está en marcha y simplemente no escucha en el puerto que elegiste.

Resultados legibles en iPhone y iPad

La vista de iOS y iPadOS no es un volcado de registro. Cuatro tarjetas muestran enviados, recibidos, porcentaje de pérdida y RTT medio; un gráfico de barras dibuja cada sonda en orden, los aciertos en verde y los fallos en rojo, de modo que una ráfaga de pérdida o una latencia al alza se ven de un vistazo. Debajo, cada sonda aparece de la más reciente a la más antigua, con su número de secuencia y su RTT.

Ejecuciones en directo que puedes detener

En escritorio la salida llega línea a línea mientras la ejecución sigue en marcha, con una píldora «Ejecutando…» en la cabecera de la tarjeta y autodesplazamiento en el panel de registro. Detener cancela al instante en lugar de esperar a las sondas restantes, útil cuando un host agota el tiempo de espera y cada sonda cuesta tres segundos. En iPhone y iPad, un botón de la barra de herramientas borra los resultados de la ejecución anterior.

Gratis en todas las plataformas

El ping no es una función Pro en ninguna parte. Ninguna de las seis herramientas de red de SSHive pasa por la comprobación de licencia en Mac, iPhone o iPad: funcionan en el nivel gratuito, sin anuncios y sin cuenta que crear. SSHive Pro es una compra única aparte que levanta los límites del nivel gratuito y desbloquea las sesiones RDP y VNC, los túneles remotos, el modo broadcast y lo demás, no el diagnóstico.

Cómo hacerlo, paso a paso

  1. 1

    Abre las herramientas de red en el Mac

    En la app de macOS, haz clic en el icono de red de la barra lateral izquierda (su descripción emergente dice Herramientas de red) o en la píldora Herramientas de red de la pantalla de bienvenida. Cualquiera de los dos abre una pestaña propia junto a tus sesiones, con todo el panel de diagnóstico. Ping es la primera tarjeta de la sección Alcanzabilidad, en la parte inferior del panel.

  2. 2

    O abre la pestaña Herramientas en iPhone y iPad

    En el iPhone, toca Herramientas en la barra de pestañas inferior (el icono de red) y elige Ping, la primera fila de la sección Diagnóstico. En el iPad, abre Herramientas de red en la barra lateral de la vista dividida y elige Ping en esa misma lista. La herramienta se comporta igual en ambos; solo cambia la disposición de la navegación.

  3. 3

    Introduce el host que quieres sondear

    Escribe un nombre de host o una dirección IP en el campo; el texto de marcador sugiere algo como google.com. ICMP es el modo predeterminado y no necesita puerto. Si cambias al motor TCP porque el host filtra el ICMP, ahí sí importa el puerto: elige uno en el que esperes que el host esté escuchando.

  4. 4

    Lanza la prueba y síguela en directo

    Pulsa Ping en escritorio, o inicia la ejecución en iOS. El registro de escritorio se llena línea a línea en un panel monoespaciado con autodesplazamiento mientras en la cabecera aparece una píldora «Ejecutando…»; Detener cancela en el acto. En iPhone y iPad, las cuatro tarjetas de estadísticas y el gráfico de barras de RTT se actualizan sonda a sonda a medida que llegan los veinte resultados.

  5. 5

    Lee el resumen

    Lee el bloque de estadísticas final: paquetes transmitidos y recibidos, porcentaje de pérdida y tiempo de ida y vuelta min/media/máx/desviación. En el motor TCP aparecen esas mismas cuatro cifras, menos la desviación típica. En iPhone y iPad están en las tarjetas Enviados, Recibidos, Pérdida y Media, encima de la lista de sondas.

Cómo leer un resultado de ping sin engañarte

Empieza por la dispersión, no por la media. Una ejecución que informa de min/media/máx de 24/26/28 ms describe una ruta sana. Una que informa de 24/58/410 ms tiene el mismo suelo, pero está encolando mal en algún punto, y la media lo esconde. La línea de estadísticas te da una cuarta cifra, la desviación típica: ese es tu valor de jitter. Unos pocos milisegundos están bien; una desviación que se acerca a la media o la supera significa que la ruta es inestable, y todo lo que sea tiempo real (VoIP, escritorio remoto, teclear en una sesión SSH interactiva) se sentirá mal aunque las descargas grandes sigan completándose con normalidad. La pérdida de paquetes necesita contexto, y el porcentaje por sí solo no sirve casi de nada. Mira los valores icmp_seq o el orden de las sondas para ver qué forma tiene. Diez sondas con un hueco suelto en medio son un 10 % sobre el papel, pero suele ser un único paquete ICMP al que un router con cosas mejores que hacer dio menos prioridad; TCP lo retransmite y no te enteras. Diez sondas en las que los números 4, 5, 6 y 7 desaparecen seguidos son otra cosa (una caída de enlace, un reencaminamiento o un salto entre puntos Wi-Fi) y frenarán de forma visible una sesión interactiva. En Wi-Fi y en móvil, una pérdida aislada de vez en cuando es rutina. Una pérdida sostenida en una ruta cableada es una avería que merece investigarse, y un traceroute te ayuda a encontrar el salto en el que empieza. Lee también el campo ttl. Los hosts empiezan en 64 (Linux, BSD, macOS), 128 (Windows) o 255 (muchos equipos de red), y cada router le resta uno. Una respuesta con ttl=52 vino de algo que empezó en 64 y cruzó doce saltos: una comprobación rápida de que estás hablando con la máquina que crees, y una pista sobre qué familia de sistema operativo respondió. La primera sonda suele ser la más lenta. La culpa es de ARP o el descubrimiento de vecinos, de la resolución DNS y de una caché de rutas fría, no del servidor. Juzga la ejecución a partir de la segunda sonda. Por último, no leas un 100 % de pérdida como «caído». Muchos hosts, CDN y redes de borde descartan el echo ICMP por política. Y en el motor TCP la semántica cambia por completo: estás cronometrando un handshake de tres vías al puerto que elegiste, así que cada valor arrastra el coste de establecer la conexión por encima de la ida y vuelta real de red, y un host cuyo cortafuegos descarta ese puerto en silencio informa de pérdida total estando perfectamente sano. La anotación de puerto cerrado es el buen desenlace: significa que el host respondió con un reset.

Preguntas frecuentes

¿Se puede hacer ping de verdad desde un iPhone?+
Sí, con ICMP real. iOS no trae terminal ni un comando ping accesible al usuario, y Network.framework, la API de red de alto nivel de Apple, no tiene ningún transporte ICMP, que es la razón por la que muchas apps de iOS sustituyen discretamente un handshake TCP. SSHive baja por debajo de esa API hasta un socket BSD de datagramas, socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), el mismo que usa el ejemplo SimplePing del propio Apple. No necesita jailbreak ni ningún entitlement especial, y envía peticiones Echo auténticas. Se sigue ofreciendo una sonda TCP para hosts que filtran el ICMP, claramente señalada como tal.
¿SSHive envía paquetes ICMP de verdad?+
En todas las versiones para Apple: la del Mac App Store, el iPhone y el iPad envían peticiones Echo ICMP auténticas y leen las Echo Reply, diez sondas en el Mac y veinte en iPhone y iPad, con el TTL y el tiempo de ida y vuelta de cada respuesta. No hay una versión de segunda. La sonda TCP connect sigue existiendo, pero como elección explícita para hosts que filtran el ICMP, y cuando se ejecuta la tarjeta lleva una etiqueta TCP, para que una comprobación de alcanzabilidad no se confunda nunca con una medida de latencia.
Un sitio funciona en mi navegador pero el ping muestra un 100 % de pérdida. ¿Por qué?+
Dos causas frecuentes. Primera: muchos hosts, CDN y cortafuegos de borde descartan el echo ICMP por política; el servidor está bien, simplemente se niega a contestar a ese tipo de sonda. Ese es justo el momento de cambiar al motor TCP y apuntar a un puerto que el host sirva de verdad. Segunda: si ya estás en el motor TCP, revisa el puerto. Un host que solo sirve HTTPS en el 443 informa de pérdida total en el puerto 80 estando perfectamente sano. Contrasta con una consulta DNS que estás probando la dirección que el navegador alcanza en realidad, antes de concluir que algo está caído.
¿Puedo cambiar el puerto, el número de sondas o el tamaño del paquete?+
En general no. Eliges el motor (ICMP o TCP) y, en el motor TCP, el puerto. Más allá de eso la ejecución es fija: diez sondas en el Mac, veinte en iPhone y iPad, sin ajustes de tamaño de paquete, intervalo ni recuento. Los destinos IPv6 se gestionan automáticamente en vez de mediante un modo aparte. Si necesitas opciones arbitrarias en un Mac, el Terminal sigue ahí: el Ping de SSHive está hecho para dar una respuesta rápida y honesta, no para replicar todas las opciones de la CLI.
¿Por qué las latencias de SSHive son más altas que las del ping en el Terminal?+
Porque en el motor TCP no estás midiendo lo mismo. La pila de red del destino contesta a un echo ICMP casi de inmediato. Una sonda TCP tiene que completar un handshake de tres vías, y la cola de escucha del destino, el planificador del sistema operativo y cualquier equipo intermedio de la ruta suman lo suyo. Cuenta con que los valores de TCP connect queden por encima de la ida y vuelta ICMP equivalente para el mismo host. Compara un host consigo mismo a lo largo del tiempo, en lugar de comparar un motor con el otro.
¿Cuánta pérdida de paquetes es realmente un problema?+
El patrón importa más que el porcentaje. Las pérdidas sueltas y aisladas en Wi-Fi o en móvil son rutina y TCP las retransmite sin que se note. Varias pérdidas consecutivas apuntan a una caída de enlace, un reencaminamiento o un cambio de punto Wi-Fi, y frenarán de forma visible las sesiones interactivas. Una pérdida sostenida en una ruta cableada merece investigarse. Y una pérdida que solo se mide contra el objetivo del ping, mientras el rendimiento en el resto sigue normal, suele significar limitación de tasa de ICMP en ese host, no una avería de red real.
¿La herramienta Ping es gratis o forma parte de Pro?+
Gratis, en todas las plataformas. Ninguna de las seis herramientas de red de SSHive (ping, traceroute, consulta DNS, whois, consulta MX y comprobación DNSBL) pasa por una comprobación de licencia en Mac, iPhone o iPad. SSHive Pro es un pago único aparte (unos 14,99 €, compra universal para Mac, iPhone y iPad, sin suscripción y sin cuenta) que levanta los límites del nivel gratuito en sesiones SSH, perfiles y túneles, y desbloquea RDP y VNC. El diagnóstico funciona en el nivel gratuito, sin anuncios.

Por qué el ICMP es un privilegio, y qué hace SSHive en su lugar

Ping no es una sola cosa. La herramienta clásica envía una petición Echo ICMP (tipo 8) y espera una respuesta Echo (tipo 0), las empareja por identificador y número de secuencia y resta las marcas de tiempo. El ICMP no tiene puertos ni sockets corrientes; para emitir uno necesitas o bien un socket raw o bien, en Darwin, un socket ICMP de datagramas (SOCK_DGRAM con IPPROTO_ICMP). Históricamente eso significaba root. En macOS moderno el bit setuid ha desaparecido de /sbin/ping: Darwin deja que cualquier proceso abra un socket ICMP de datagramas sin privilegios (SOCK_DGRAM con IPPROTO_ICMP), que es exactamente lo que usa el binario ping del sistema. /usr/sbin/traceroute, en cambio, se sigue instalando setuid root. La creencia extendida dice que el App Sandbox de Apple prohíbe todo esto. No lo hace, y merece la pena afinar la distinción. Una aplicación del Mac App Store en sandbox tiene com.apple.security.network.client, que autoriza TCP y UDP salientes. Un socket raw sí se rechaza de verdad, y lanzar un ayudante setuid también. Un socket ICMP de datagramas es otro objeto distinto, y el sandbox lo deja pasar. Eso se midió en lugar de suponerse, bajo sandbox-exec con los entitlements reales de la app, y el resultado esconde una trampa. Con network.client a secas, socket() funciona y sendto() funciona, pero recvfrom() devuelve EPERM. La sonda sale y no vuelve nunca, lo que se parece exactamente a una red que filtra el ICMP y se depura fatal. Hacen falta network.client y network.server para el ciclo completo. SSHive declara los dos, y por eso el ping se comporta igual dentro y fuera del sandbox. iOS parece más estricto y, en el nivel en el que trabaja la mayoría de apps, lo es: Network.framework expone TCP, UDP, QUIC y TLS, y no tiene transporte ICMP alguno. Por eso tantas apps de iOS que anuncian un «ping» están cronometrando en realidad un handshake TCP. Pero Network.framework no es el suelo. La capa de sockets BSD que hay debajo sigue presente y sigue permitida, y socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) es precisamente lo que abre el ejemplo SimplePing del propio Apple. SSHive también lo abre, con IPPROTO_ICMPV6 para destinos IPv6. Así que hay un solo comportamiento que aprender, no cuatro. En macOS el trabajo ocurre en un pequeño complemento nativo N-API; en iPhone y iPad, en un tipo Swift construido sobre el mismo socket. Ambos montan la petición Echo por su cuenta, calculan la suma de comprobación ICMP y fijan IP_TTL cuando un traceroute lo necesita. Ambos emparejan las respuestas con cuatro criterios (identificador, número de secuencia, dirección de origen y una cookie aleatoria de ocho bytes en la carga útil), porque un socket ICMP de datagramas recibe una copia de todas las respuestas ICMP que llegan a la máquina, incluidas las destinadas a otros procesos. Dos ejecuciones simultáneas contra hosts distintos no se contaminan entre sí. La sonda TCP connect no ha desaparecido; se ha degradado al papel que siempre debió tener. Muchos hosts descartan el ICMP en el borde mientras sirven el tráfico a la perfección, y para esos un handshake contra un puerto que tú indiques es la medida honesta. Se ofrece como elección deliberada, etiquetada con una insignia TCP, y solo se usa automáticamente si el módulo ICMP nativo no consigue cargarse. Sus contrapartidas siguen en pie: la latencia incluye el coste del handshake, así que las cifras salen más altas que una ida y vuelta ICMP real contra el mismo host, y un host que responde al ICMP pero descarta el puerto que elegiste se lee como pérdida total.

Herramientas relacionadas

Traceroute

Consulta DNS