Question Pourquoi MacOSX essaie-t-il de résoudre les adresses IP complétées par zéro en tant que noms d'hôte?


Celui-ci a causé des maux de tête à un ami lors de la mise en place d'une connexion Internet commutée qui avait comme adresse:

192.168.019.254

Peu importe comment il a essayé de configurer la pile réseau Mac, cela n'a tout simplement pas fonctionné. Mais l'interface graphique ne s'est pas plaint également des erreurs.

J'ai découvert plus tard que le ping de ces adresses nulles dans un terminal montrait "impossible à résoudre" en envoyant une commande ping à la même adresse sans zéros remplis (192.168.19.254 contre. 192.168.019.254) a montré "incapable d'atteindre" ce qui a apporté beaucoup de lumière dans ce mysterium. En supprimant les zéros inutiles, tout fonctionnait.

Est-ce un bug ou une fonctionnalité? Je n'ai jamais connu un comportement aussi étrange auparavant, que j'utilise l'interface graphique ou l'interface de ligne de commande pour configurer ou tester des éléments IP.


4
2018-02-15 00:17


origine




Réponses:


La traduction d'une chaîne en une adresse est généralement effectuée par la fonction POSIX getaddrinfo(). Cette fonction vérifie d’abord une adresse IP numérique en utilisant inet_addr(), et si cela échoue, il tentera ensuite de résoudre la chaîne en tant que nom de domaine. inet_addr() interprète les nombres avec un 0 comme octal, donc par exemple 010 deviendrait 8, et 019 serait une erreur (et serait donc résolu en tant que nom de domaine). Le même comportement se produit également sous Linux et Solaris.

De getaddrinfo():

Si la famille d'adresses spécifiée est AF_INET ou AF_UNSPEC, les chaînes d'adresse   en utilisant la notation par points standard Internet spécifiée dans inet_addr() sont valides.

De inet_addr():

Tous les nombres fournis en tant que parties en notation décimale pointée IPv4 peuvent être décimaux, octaux ou hexadécimaux, comme spécifié dans la norme ISO C (c'est-à-dire qu'un 0x ou 0X en tête implique un hexadécimal; sinon, un 0 signifie un octal; le nombre est interprété comme décimal).

Notez l'adresse 192.168.8.254 entre parenthèses:

$ ping 192.168.010.254
PING 192.168.010.254 (192.168.8.254): 56 data bytes
Request timeout for icmp_seq 0

10
2018-02-15 02:11



Okay ce joli contre-intuitif mais pourrait être utile. Pourtant, il n'explique pas pourquoi 192.168.010.254 n'a pas été en mesure de résoudre alors que 192.168.10.254 n'a pas pu atteindre. Ne devraient-ils pas tous les deux être incapables d'atteindre? - hurikhan77
Cela me frappe comme un flash: En parlant de nombres octaux, je me souviens que l'IP d'origine en question était quelque chose comme xxx.xxx.019.xxx - qui n'est bien sûr pas un numéro valide et donc un nom d'hôte invalide. Modifier ma question ... - hurikhan77
J'ai mis à jour ma réponse pour répondre à la question mise à jour. - mark4o
+1 et pour la grande explication. Reste à savoir pourquoi l'interface graphique de Mac OS ne permet pas d'interpréter les nombres décimaux comme il se doit. Cependant, le papier de configuration du FAI est tout simplement faux. J'ai testé sur une machine Windows (car elle est non-posix) qui présente la même interprétation sur CLI - elle ne le fait toutefois pas sur l'interface graphique. - hurikhan77
@ hurikhan77 Vous l'avez. Ce n'est pas une adresse IP valide, car 9 n'est pas un chiffre octal légal, la règle est donc de le traiter comme un nom d'hôte. - David Schwartz