Aller au contenu principal
Obtenir

Envoyez un ping vers n'importe quel hôte depuis Mac, iPhone ou iPad

De vraies requêtes ICMP sur Mac, iPhone et iPad, et la latence, la perte et la gigue qu'il faut savoir lire.

Par Lucas Russo, développeur de SSHive · Mis à jour le

Télécharger SSHive gratuitementTous les outils réseau
Aussi sur iPhone et iPad
Une page met huit secondes à s'afficher, une session SSH se fige au milieu d'une commande, un appel visio devient un diaporama. Avant de toucher à quoi que ce soit, il vous faut deux chiffres : le temps réel d'un aller-retour vers l'hôte, et le nombre de sondes qui ne sont jamais revenues. C'est exactement ce que donne le ping, et cela reste le moyen le plus rapide de distinguer « le serveur est tombé » de « le chemin vers le serveur est mauvais ». Obtenir ces chiffres sur du matériel Apple est plus compliqué qu'il n'y paraît. macOS a longtemps livré l'Utilitaire de réseau et son onglet Ping ; il a été déprécié dans Big Sur, ne fonctionnait plus sous Monterey, et il est absent des versions actuelles de macOS. Le Terminal existe toujours, mais c'est un détour peu naturel quand on travaille déjà dans un gestionnaire de sessions. Sur iPhone et iPad, il n'y a tout simplement rien à ouvrir : iOS n'expose aucun shell, donc ping n'est pas une commande que vous pouvez lancer, seulement une capacité qu'une application doit implémenter. SSHive l'implémente lui-même sur chacune de ses plateformes Apple : iPhone, iPad et la version Mac App Store. Toutes envoient de véritables requêtes echo ICMP (dix sur Mac, vingt sur iPhone et iPad) et rapportent le temps d'aller-retour de chaque réponse, le TTL avec lequel elle revient, et le nombre de sondes perdues. Cela mérite d'être dit, car on tient généralement la chose pour impossible dans le bac à sable d'Apple. Cette idée confond deux objets différents. Un socket brut exige bien les privilèges root, et le bac à sable le refuse. Un socket ICMP datagramme (socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)) n'exige ni l'un ni l'autre : Darwin l'accorde aux processus non privilégiés, et le bac à sable l'autorise. C'est le mécanisme du code d'exemple SimplePing d'Apple, celui qui tourne sur iOS. SSHive ouvre ce socket directement, si bien que la version App Store, sous bac à sable, mesure de vrais allers-retours plutôt qu'une approximation. Une sonde TCP vers un port de votre choix reste disponible, et c'est le bon outil quand l'ICMP est filtré de bout en bout. C'est un choix explicite dans l'interface, pas une substitution silencieuse : la carte vous dit quel moteur a produit les chiffres que vous lisez. L'outil est gratuit sur toutes les plateformes. Aucun des outils réseau de SSHive n'est réservé à Pro, et il n'y a ni publicité ni compte à créer.

Ce que fait SSHive

Du vrai ICMP sur toutes les plateformes Apple

SSHive envoie des requêtes echo ICMP (dix sur Mac, vingt sur iPhone et iPad) depuis un socket datagramme non privilégié et diffuse chaque réponse à son arrivée, dans la forme BSD habituelle : numéro de séquence, TTL et temps d'aller-retour par ligne, puis un bloc final avec la perte de paquets et le min/moy/max/écart-type. Le même moteur tourne dans la version Mac App Store, sur iPhone et sur iPad : les chiffres sont donc comparables d'un appareil à l'autre. L'appariement des réponses se fait sur quatre critères, dont un cookie aléatoire de huit octets dans la charge utile, car un socket ICMP datagramme reçoit aussi une copie des réponses destinées aux autres processus.

Sonde TCP là où ICMP est filtré

Beaucoup d'hôtes jettent l'ICMP en bordure de réseau tout en servant parfaitement le trafic, et un pare-feu qui avale les requêtes echo fait passer un serveur en pleine santé pour un serveur mort. Pour ceux-là, SSHive peut ouvrir une connexion TCP vers un port que vous désignez et chronométrer la poignée de main. La carte signale la série par un badge TCP, pour qu'un test de joignabilité ne soit jamais pris pour une mesure de latence. C'est aussi le repli automatique si le module ICMP natif ne peut pas être chargé.

Une connexion refusée compte comme joignable

Quand vous choisissez délibérément le moteur TCP, un reset est une preuve de vie : l'hôte a reçu votre SYN et y a répondu. SSHive compte une connexion refusée comme une sonde réussie et annote la ligne « port fermé » au lieu de la marquer perdue. Cette nuance vous évite de déclarer une panne alors que la machine tourne et n'écoute simplement pas sur le port que vous avez choisi.

Des résultats lisibles sur iPhone et iPad

La vue iOS et iPadOS n'est pas un vidage de log. Quatre cartes affichent les envoyés, les reçus, le pourcentage de perte et le RTT moyen ; un graphique en barres trace chaque sonde dans l'ordre, réussites en vert et échecs en rouge, pour repérer d'un coup d'œil une rafale de pertes ou une latence qui grimpe. Dessous, chaque sonde est listée de la plus récente à la plus ancienne, avec son numéro et son RTT.

Des tests en direct, interruptibles

Sur ordinateur, la sortie arrive ligne par ligne pendant l'exécution, avec une pastille « En cours… » dans l'en-tête et un défilement automatique du volet de log. Arrêter annule immédiatement au lieu d'attendre les sondes restantes : pratique quand un hôte ne répond pas et que chaque sonde coûte trois secondes. Sur iPhone et iPad, un bouton de la barre d'outils efface les résultats précédents.

Gratuit sur toutes les plateformes

Ping n'est une fonction Pro sur aucune plateforme. Aucun des six outils réseau de SSHive n'est soumis à la vérification de licence sur Mac, iPhone ou iPad : ils tournent dans la version gratuite, sans publicité et sans compte à créer. SSHive Pro est un achat unique distinct qui lève les limites de la version gratuite et débloque les sessions RDP et VNC, les tunnels distants, le broadcast et le reste, pas les diagnostics.

Comment faire, étape par étape

  1. 1

    Ouvrez les outils réseau sur le Mac

    Dans l'application macOS, cliquez sur l'icône réseau de la barre latérale gauche (son infobulle indique Outils réseau), ou sur la pastille Outils réseau de l'écran d'accueil. L'une comme l'autre ouvre un onglet dédié à côté de vos sessions, avec tout le panneau de diagnostic. Ping est la première carte de sa section Joignabilité, en bas du panneau.

  2. 2

    Ou ouvrez l'onglet Outils sur iPhone et iPad

    Sur iPhone, touchez Outils dans la barre d'onglets du bas (l'icône réseau), puis choisissez Ping, première ligne de la section Diagnostic. Sur iPad, ouvrez Outils réseau dans la barre latérale et sélectionnez Ping dans la même liste. L'outil se comporte de façon identique ; seule la navigation change.

  3. 3

    Saisissez l'hôte à tester

    Saisissez un nom d'hôte ou une adresse IP dans le champ ; le texte indicatif propose par exemple google.com. L'ICMP est le mode par défaut et ne demande aucun port. Si vous basculez sur le moteur TCP parce que l'hôte filtre l'ICMP, c'est là que le port compte : choisissez-en un sur lequel l'hôte est censé écouter.

  4. 4

    Lancez le test et suivez-le en direct

    Appuyez sur Ping sur ordinateur, ou lancez le test sur iOS. Le log se remplit ligne par ligne dans un volet monospace à défilement automatique, avec une pastille « En cours… » dans l'en-tête ; Arrêter interrompt sur-le-champ. Sur iPhone et iPad, les quatre cartes de statistiques et le graphique de RTT se mettent à jour sonde après sonde, au fil des vingt résultats.

  5. 5

    Lisez le récapitulatif

    Lisez le bloc de statistiques final : paquets transmis et reçus, pourcentage de perte, et aller-retour min/moy/max/écart-type. Sur le moteur TCP, on retrouve les mêmes quatre chiffres, sans l'écart-type. Sur iPhone et iPad, ils figurent dans les cartes Envoyés, Reçus, Perte et Moyenne, au-dessus de la liste des sondes.

Lire une sortie de ping sans se tromper

Commencez par l'écart, pas par la moyenne. Un test qui affiche min/moy/max à 24/26/28 ms décrit un chemin sain. Un test à 24/58/410 ms a le même plancher mais met en file d'attente quelque part, et la moyenne le masque. La ligne de statistiques ajoute un quatrième chiffre, l'écart-type : c'est votre mesure de gigue. Quelques millisecondes, c'est normal ; un écart-type qui approche ou dépasse la moyenne signale un chemin instable, et tout ce qui est temps réel (VoIP, bureau à distance, frappe interactive en SSH) sera désagréable même si les téléchargements passent encore correctement. La perte de paquets demande du contexte : le pourcentage seul ne vaut presque rien. Regardez les valeurs icmp_seq ou l'ordre des sondes pour en voir la forme. Dix sondes avec un trou isolé au milieu, cela fait 10 % sur le papier, mais c'est en général un paquet ICMP déprioritisé par un routeur occupé ailleurs ; TCP le retransmet et vous ne voyez rien. Dix sondes où les numéros 4, 5, 6 et 7 disparaissent d'affilée, c'est tout autre chose (coupure de lien, reroutage ou changement de borne Wi-Fi) et la session interactive le ressentira nettement. En Wi-Fi et en cellulaire, une perte isolée occasionnelle est banale. Une perte soutenue sur un lien filaire mérite une enquête, et un traceroute aide à trouver le saut où elle commence. Lisez aussi le champ ttl. Les hôtes partent de 64 (Linux, BSD, macOS), 128 (Windows) ou 255 (beaucoup d'équipements réseau), et chaque routeur le décrémente de un. Une réponse avec ttl=52 vient d'une machine partie de 64 et a traversé douze sauts : vérification rapide que vous parlez bien à la bonne machine, et indice sur la famille d'OS qui a répondu. La première sonde est souvent la plus lente. Mettez cela sur le compte d'ARP ou de la découverte de voisins, de la résolution DNS et d'un cache de route froid, pas du serveur. Jugez le test à partir de la deuxième sonde. Enfin, ne lisez pas 100 % de perte comme « hôte en panne ». Beaucoup d'hôtes, de CDN et de réseaux de bordure jettent l'echo ICMP par politique. Et sur le moteur TCP, la sémantique change complètement : vous chronométrez une poignée de main en trois temps vers le port choisi, donc chaque valeur intègre le coût d'établissement de connexion en plus du véritable aller-retour réseau, et un hôte dont le pare-feu jette ce port en silence affichera 100 % de perte tout en se portant très bien. L'annotation « port fermé » est la bonne nouvelle : elle signifie que l'hôte a répondu par un reset.

Questions fréquentes

Peut-on vraiment faire un ping depuis un iPhone ?+
Oui, avec du vrai ICMP. iOS ne fournit ni terminal ni commande ping accessible, et Network.framework, l'API réseau de haut niveau d'Apple, n'expose aucun transport ICMP, ce qui pousse beaucoup d'applications iOS à substituer discrètement une poignée de main TCP. SSHive descend sous cette API jusqu'à un socket BSD datagramme, socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), celui-là même qu'utilise l'exemple SimplePing d'Apple. Il ne demande ni jailbreak ni entitlement particulier, et il envoie de véritables requêtes Echo. Une sonde TCP reste proposée pour les hôtes qui filtrent l'ICMP, clairement signalée comme telle.
SSHive envoie-t-il de vrais paquets ICMP ?+
Sur toutes les versions Apple : la version Mac App Store, l'iPhone et l'iPad envoient de véritables requêtes Echo ICMP et lisent les réponses Echo, dix sondes sur Mac et vingt sur iPhone et iPad, avec le TTL et le temps d'aller-retour de chaque réponse. Il n'y a pas de version au rabais. La sonde TCP existe toujours, mais comme choix explicite pour les hôtes qui filtrent l'ICMP, et quand elle tourne, la carte porte un badge TCP, pour qu'un test de joignabilité ne soit jamais pris pour une mesure de latence.
Un site marche dans mon navigateur mais le ping affiche 100 % de perte. Pourquoi ?+
Deux causes fréquentes. D'abord, beaucoup d'hôtes, de CDN et de pare-feux de bordure jettent l'echo ICMP par politique : le serveur va bien, il refuse simplement de répondre à ce type de sonde. C'est précisément le moment de basculer sur le moteur TCP et de viser un port réellement servi. Ensuite, si vous êtes déjà sur le moteur TCP, vérifiez le port : un hôte qui ne sert que du HTTPS sur 443 affichera 100 % de perte sur le port 80 en étant parfaitement sain. Vérifiez avec une recherche DNS que vous testez bien l'adresse que le navigateur atteint avant de conclure à une panne.
Peut-on changer le port, le nombre de sondes ou la taille des paquets ?+
Pas vraiment. Vous choisissez le moteur (ICMP ou TCP) et, sur le moteur TCP, le port. Au-delà, la série est figée : dix sondes sur Mac, vingt sur iPhone et iPad, sans réglage de taille de paquet, d'intervalle ni de nombre. Les destinations IPv6 sont prises en charge automatiquement plutôt que par un mode distinct. Si vous avez besoin d'options arbitraires sur Mac, le Terminal est toujours là ; le Ping de SSHive vise une réponse rapide et honnête, pas la réplication complète de la CLI.
Pourquoi les latences de SSHive sont-elles plus hautes que celles du ping du Terminal ?+
Parce que sur le moteur TCP vous ne mesurez pas la même chose. Un echo ICMP est traité presque immédiatement par la pile réseau de la cible. Une sonde TCP doit achever une poignée de main en trois temps, et la file d'attente du service visé, l'ordonnanceur du système et le moindre équipement intermédiaire s'y ajoutent. Attendez-vous à des valeurs TCP supérieures à l'aller-retour ICMP équivalent pour le même hôte. Comparez un hôte à lui-même dans le temps, pas un moteur à l'autre.
À partir de quel taux la perte de paquets devient-elle un problème ?+
La forme compte plus que le pourcentage. Des pertes isolées en Wi-Fi ou en cellulaire sont banales, TCP les retransmet sans que vous le voyiez. Plusieurs pertes consécutives évoquent une coupure de lien, un reroutage ou un changement de borne, et bloqueront visiblement une session interactive. Une perte soutenue sur un lien filaire mérite une investigation. Et une perte constatée uniquement sur la cible du ping, alors que le débit reste normal ailleurs, traduit le plus souvent une limitation de débit ICMP sur cet hôte, pas une vraie panne réseau.
L'outil Ping est-il gratuit ou réservé à Pro ?+
Gratuit, sur toutes les plateformes. Aucun des six outils réseau de SSHive (ping, traceroute, recherche DNS, whois, recherche MX et vérification DNSBL) n'est soumis à une vérification de licence sur Mac, iPhone ou iPad. SSHive Pro se paie une seule fois (environ 14,99 €, achat universel pour Mac, iPhone et iPad, sans abonnement ni compte) ; il lève les limites de la version gratuite sur les sessions SSH, les profils et les tunnels, et débloque RDP et VNC. Les diagnostics tournent dans la version gratuite, sans publicité.

Pourquoi ICMP est un privilège, et ce que SSHive fait à la place

Le ping n'est pas une chose unique. L'outil classique envoie une requête ICMP Echo (type 8) et attend une réponse Echo (type 0), les apparie par identifiant et numéro de séquence, puis soustrait les horodatages. ICMP n'a ni ports ni sockets ordinaires ; pour en émettre un, il faut soit un socket brut, soit, sur Darwin, un socket ICMP datagramme (SOCK_DGRAM avec IPPROTO_ICMP). Historiquement, cela voulait dire root. Sur macOS moderne, le bit setuid a disparu de /sbin/ping : Darwin autorise n'importe quel processus à ouvrir un socket ICMP datagramme non privilégié (SOCK_DGRAM avec IPPROTO_ICMP), et c'est ce qu'utilise le binaire système. /usr/sbin/traceroute, lui, reste installé setuid root. L'idée reçue veut que le bac à sable d'Apple interdise tout cela. C'est faux, et la nuance mérite d'être posée. Une application Mac App Store sandboxée détient com.apple.security.network.client, qui autorise le TCP et l'UDP sortants. Un socket brut est effectivement refusé, et lancer un binaire setuid également. Un socket ICMP datagramme est un objet différent, et le bac à sable le laisse passer. Cela a été mesuré plutôt que supposé, sous sandbox-exec avec les entitlements réels de l'application, et le résultat recèle un piège. Avec network.client seul, socket() réussit et sendto() réussit, mais recvfrom() renvoie EPERM. La sonde part et ne revient jamais, ce qui ressemble exactement à un réseau qui filtre l'ICMP et se débogue très mal. Il faut network.client et network.server pour que le cycle complet fonctionne. SSHive déclare les deux, et c'est la raison pour laquelle le ping se comporte de façon identique dans et hors du bac à sable. iOS paraît plus strict et, au niveau où travaillent la plupart des applications, il l'est : Network.framework expose TCP, UDP, QUIC et TLS, et n'offre aucun transport ICMP. D'où le nombre d'applications iOS annonçant un « ping » qui chronomètrent en réalité une poignée de main TCP. Mais Network.framework n'est pas le plancher. La couche de sockets BSD qui se trouve dessous est toujours présente et toujours autorisée, et socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) est exactement ce qu'ouvre l'exemple SimplePing d'Apple. SSHive l'ouvre aussi, avec IPPROTO_ICMPV6 pour les destinations IPv6. Il n'y a donc qu'un seul comportement à connaître, pas quatre. Sur macOS le travail se fait dans un petit addon natif N-API ; sur iPhone et iPad dans un type Swift bâti sur le même socket. Les deux assemblent eux-mêmes la requête Echo, calculent la somme de contrôle ICMP et positionnent IP_TTL quand un traceroute le demande. Les deux apparient les réponses sur quatre critères (identifiant, numéro de séquence, adresse source et un cookie aléatoire de huit octets placé dans la charge utile) car un socket ICMP datagramme reçoit une copie de toutes les réponses ICMP de la machine, y compris celles destinées aux autres processus. Deux séries simultanées vers des hôtes différents ne se contaminent pas. La sonde TCP n'a pas disparu : elle a été ramenée au rôle qui aurait toujours dû être le sien. Beaucoup d'hôtes jettent l'ICMP en bordure tout en servant parfaitement le trafic, et pour ceux-là une poignée de main vers un port que vous désignez est la mesure honnête. Elle est proposée comme choix délibéré, signalée par un badge TCP, et utilisée automatiquement seulement si le module ICMP natif ne se charge pas. Ses compromis demeurent : la latence inclut le coût de la poignée de main, donc les chiffres dépassent un véritable aller-retour ICMP vers le même hôte, et un hôte qui répond en ICMP mais filtre le port choisi s'affiche à 100 % de perte.

Outils liés

Traceroute

Recherche DNS