adresse destination 0.0.0.0 invalide ?
Thierry B.
démonstration évidente de mes doutes...
-------------------------------------------
tth@gally:~$ uname -a
Linux gally 2.6.12-10-686 #1 Wed Feb 7 03:56:37 UTC 2007 i686 GNU/Linux
tth@gally:~$ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
Wed May 14 13:27:04 2008
-------------------------------------------
tth@puce ~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
tth@puce ~ $ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
telnet: connect to address 0.0.0.0: Invalid argument
tth@puce ~ $ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Wed May 14 14:27:25 2008
-------------------------------------------
En poussant un peu plus loin, on se rend vite compte que Linux
redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.
Par exemple, on retrouve bien 127.0.0.1 dans le log apache
avec un "lynx http://0.0.0.0/". Pourtant, l'adresse 0.0.0.0
est semble-t-il invalide comme destination pour les RFCs.
J'aimerais bien savoir si ce comportement est normal, dangereux,
justifié, toussa. Et où le trouver dans les sources de la kernelle.
Et il y a un fil en cours sur ce sujet dans fcr.ip aussi...
Merci de votre attention.
--
Je suis très siècle dernier, à ce niveau.
--
Pour contacter l'équipe de modération : moderate...@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
olivier...@free.fr
> est semble-t-il invalide comme destination pour les RFCs.
>
> J'aimerais bien savoir si ce comportement est normal, dangereux,
> justifié, toussa. Et où le trouver dans les sources de la kernelle.
> Et il y a un fil en cours sur ce sujet dans fcr.ip aussi...
>
> Merci de votre attention.
>
> --
> Je suis très siècle dernier, à ce niveau.
>
> --
> ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
> la liste de distribution des modérateurs.
sans pouvoir donner de plus amples explications, effectivement le
0.0.0.0 est bien une adresse non joignable.
le comportement de ton BSD est correct. Ce qui m'empeche pas d'avoir
constate sur une plateforme OpenBSD + QMail une faille via l'adresse
0.0.0.0.
j'avais du patcher QMail pour cela.
Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
--> telnet dans ton cas.
Cdlt,
Olivier
xtof.pernod
>> En poussant un peu plus loin, on se rend vite compte que Linux
>> redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.
En effet..
# tcpdump -i lo -vvv&
# ping 0.0.0.0
PING 0.0.0.0 (0.0.0.0): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 time=0 ms
14:52:32.238085 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ICMP (1), length: 84) 127.0.0.1 > 127.0.0.1: ICMP
echo request, id 41060, seq 0, len 64
..on voit bien que le noyau a mis 127.0.0.1 en source et en destination.
>> J'aimerais bien savoir si ce comportement est normal, dangereux,
normal, non.. C'est BSD qui doit avoir raison.
dangereux ? en injectant cette adresse à la place d'une réelle,
il doit etre possible de faire des trucs marrants, détourner du
traffic, tout ça..
>> justifié, toussa. Et où le trouver dans les sources de la kernelle.
Dans celui que j'ai sous la main: il y a une affectation de
INADDR_LOOPBACK (127.0.0.1, bien sûr) à 2 variables (dst et src)
dans /usr/src/linux-2.6.23.12/net/ipv4/route.c, L. 2245::
if (!fl.fl4_dst) {
fl.fl4_dst = fl.fl4_src;
if (!fl.fl4_dst)
fl.fl4_dst = fl.fl4_src = htonl(INADDR_LOOPBACK);
Peut-être une piste !? (si c'est pas là, je vois pas où c'est =)
olivier...@free.fr a écrit :
> Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
> --> telnet dans ton cas.
Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)
<ml-26_XtoX-0.23d /]# tftp 0.0.0.0 -c get /xx /tmp/yy
14:53:17.938812 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 43) 127.0.0.1.32770 > 127.0.0.1.tftp:
[bad udp cksum 3e1c!] 15 RRQ "/xx" netascii
14:53:17.940300 IP (tos 0x0, ttl 64, id 24214, offset 0, flags [DF],
proto: UDP (17), length: 32) 127.0.0.1.32771 > 127.0.0.1.32770:
[bad udp cksum aa03!] UDP,
14:53:17.940727 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 32) 127.0.0.1.32770 > 127.0.0.1.32771:
[bad udp cksum a903!] UDP,
espoir-ceci-aide, etc.
--
christophe.
Eric Razny
> sans pouvoir donner de plus amples explications, effectivement le
> 0.0.0.0 est bien une adresse non joignable.
>
> le comportement de ton BSD est correct. Ce qui m'empeche pas d'avoir
> constate sur une plateforme OpenBSD + QMail une faille via l'adresse
> 0.0.0.0.
>
> j'avais du patcher QMail pour cela.
>
> Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
>
> --> telnet dans ton cas.
Je pense plus à un problème de resolver sous nunux.
Je viens de me frapper (en partie!) le code source de telnet d'une etch et
dans command.cc, fonction sourceroute, on a bien par exemple l'utilisation
de inet_aton et pas inet_addr. Le reste semble du même accabit (bon un
commentaire du type fixme, fuite mémoire fait désordre ;) ).
En écrivant ça il y a un moyen con de vérifier...
... c'est fait :
$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
hth.
--
Eric
xtof.pernod
> Le Tue, 10 Jun 2008 21:19:10 +0000, olivier.burelli a écrit :
> (...)
> En écrivant ça il y a un moyen con de vérifier...
> ... c'est fait :
>
> $ ping 0.0.0.0
> PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
Ca, c'est marrant.. Ton ping, il a déjà convertit
INADDR_ANY en INADDR_LOOPBACK ?!
Le mien, pas.. [cf post précédent]
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
>
> hth.
>
0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
(je pense qu'en fait on doit pas avoir la meme version de ping(1):
le mien, je suis même pas sûr qu'il soit linké avec libm, c'est
peut-être pour ça qu'il affiche que la partie entière de time=..)
> Je pense plus à un problème de resolver sous nunux.
Je penche plus pour ma version "les sources du noyau", mais en
même temps, ce que j'ai remonté, c'est 2 minutes au grep -R
et à l'éditeur..
--
christophe.
Pascal Hambourg
Eric Razny a écrit :
>
> Je pense plus à un problème de resolver sous nunux.
Hypothèse intéressante, mais je crois que c'est xtof qui a raison, étant
arrivé à la même conclusion que lui.
Pour info, cette discussion a été amorcée dans fr.comp.reseaux.ip sous
le titre "Attributions des ports".
> En écrivant ça il y a un moyen con de vérifier...
> ... c'est fait :
>
> $ ping 0.0.0.0
> PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
Qu'est-ce que c'est censé vérifier, au juste ?
tTh
>>> En poussant un peu plus loin, on se rend vite compte que Linux
>>> redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.
>
> En effet..
>
> # tcpdump -i lo -vvv&
> # ping 0.0.0.0
> PING 0.0.0.0 (0.0.0.0): 56 data bytes
> 64 bytes from 127.0.0.1: icmp_seq=0 time=0 ms
> 14:52:32.238085 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
> proto: ICMP (1), length: 84) 127.0.0.1 > 127.0.0.1: ICMP
> echo request, id 41060, seq 0, len 64
>
> ..on voit bien que le noyau a mis 127.0.0.1 en source et en destination.
>
>>> J'aimerais bien savoir si ce comportement est normal, dangereux,
>
> normal, non.. C'est BSD qui doit avoir raison.
Je pense aussi que BSD a raison. Que font les autres Unix ?
> dangereux ? en injectant cette adresse à la place d'une réelle,
> il doit etre possible de faire des trucs marrants, détourner du
> traffic, tout ça..
Surtout qu'une lecture diagonale des RFCs peut laisser penser
que 0.0.0.0 ne peut pas être une adresse destination valide,
et qu'on aura donc, à tord, tendance à l'éliminer d'une stratégie
de filtrage...
>>> justifié, toussa. Et où le trouver dans les sources de la kernelle.
>
> Dans celui que j'ai sous la main: il y a une affectation de
> INADDR_LOOPBACK (127.0.0.1, bien sûr) à 2 variables (dst et src)
> dans /usr/src/linux-2.6.23.12/net/ipv4/route.c, L. 2245::
>
> if (!fl.fl4_dst) {
> fl.fl4_dst = fl.fl4_src;
> if (!fl.fl4_dst)
> fl.fl4_dst = fl.fl4_src = htonl(INADDR_LOOPBACK);
>
> Peut-être une piste !? (si c'est pas là, je vois pas où c'est =)
>
Excusez-moi d'arriver un peu tard (c'est quand même moi qui
ai lancé le truc :). Pascal, dans fcr.ip est arrivé au même
morceau de code <g0rk1p$1flu$1...@biggoron.nerim.net> avec une
conclusion qui me semble "presque" correcte.
> Je pense pas, ca le fait au ping et aussi avec tftp
> (client ras-de-terre de tftp-hpa-0.48:)
D'après les essais que j'ai pû tenter, c'est assez général
comme comportement. Je dois avoir des sources de noyau
2.2 qui trainent quelque part, je vais aller voir ce qu'il
en est au siècle dernier. Mais j'aimerais surtout comprendre
le "pourquoi", la "motivation" du choix de ce comportement.
--
No sig available.
Eric Razny
>> Je pense plus à un problème de resolver sous nunux.
>
> Hypothèse intéressante, mais je crois que c'est xtof qui a raison, étant
> arrivé à la même conclusion que lui.
Il faudrait regarder dans les sources du noyau. Un parsing rapide ne me
donne que net/ipv4/netfilter/ipt_REDIRECT.c pour trouver 0x7F000001 mais
comme loopback est aussi trouvable par d'autre méthode ça va être
coton. Il semble aussi y avoir des trucs à voir sur sctp et en cherchant
sur INADDR_ANY mais il ne faut pas compter sur moi avant septembre pour
chercher la dedans ;)
> Pour info, cette discussion a été amorcée dans fr.comp.reseaux.ip sous
> le titre "Attributions des ports".
Merci. Je vais y jetter un oeil (enfin si j'ai le temps!)
>> En écrivant ça il y a un moyen con de vérifier...
>> ... c'est fait :
>>
>> $ ping 0.0.0.0
>> PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms
>> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
>
> Qu'est-ce que c'est censé vérifier, au juste ?
Effectivement ce n'est pas très probant au sens où on n'est quand même
pas sur que c'est pas le noyau qui fait ça au lieu du resolver voire de
ping.
J'ai bloqué un peu vite sur le 0.0.0.0 converti explicitement en
127.0.0.1 chez moi
Le plus simple va être de reprendre l'idée de xtof (tcpdump) en
écrivant rapidement une merde en C qui va ouvrir un socket et tenter de
se connecter en 0.0.0.0 sur un port quelconque en tcp par exemple (bon
formellement ça peut aussi venir des libs mais bon ;) )
xtof.pernod
> xtof.pernod wrote:
>> (...) le noyau a mis 127.0.0.1 en source et en destination.
>>
>>>> J'aimerais bien savoir si ce comportement est normal, dangereux,
>>
>> normal, non.. C'est BSD qui doit avoir raison.
>
> Je pense aussi que BSD a raison. Que font les autres Unix ?
Et que fait la police ?
Quant à un autre type de système entierement basé sur les fenêtres,
il s'en rend bien compte, mais il essaye quand même:
Pinging 0.0.0.0 with 32 bytes of data:
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Ping statistics for 0.0.0.0:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>
>> dangereux ? en injectant cette adresse à la place d'une réelle,
>> il doit etre possible de faire des trucs marrants, détourner du
>> traffic, tout ça..
>
> Surtout qu'une lecture diagonale des RFCs peut laisser penser
> que 0.0.0.0 ne peut pas être une adresse destination valide,
> et qu'on aura donc, à tord, tendance à l'éliminer d'une stratégie
> de filtrage...
>
Pinaiiiiise, oui.. Ca fait froid dans le dos ce que tu dis la.. =)
Mais j'y pense, d'un coup: comment établir une route vers 0.0.0.0 ?!
0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
comme 255.255.255.255 (?)
>>>> justifié, toussa. Et où le trouver dans les sources de la kernelle.
>>
>> Dans celui que j'ai sous la main: il y a une affectation de
>> INADDR_LOOPBACK (127.0.0.1, bien sûr) à 2 variables (dst et src)
>> dans /usr/src/linux-2.6.23.12/net/ipv4/route.c, L. 2245::
>>
>> if (!fl.fl4_dst) {
>> fl.fl4_dst = fl.fl4_src;
>> if (!fl.fl4_dst)
>> fl.fl4_dst = fl.fl4_src = htonl(INADDR_LOOPBACK);
>>
>> Peut-être une piste !? (si c'est pas là, je vois pas où c'est =)
>>
>
> Excusez-moi d'arriver un peu tard (c'est quand même moi qui
> ai lancé le truc :). Pascal, dans fcr.ip est arrivé au même
> morceau de code <g0rk1p$1flu$1...@biggoron.nerim.net> avec une
> conclusion qui me semble "presque" correcte.
Tu aurais les refs' de l'article ? Je le trouve pas (meme au gougueule)
(c'etait: ma manière de dire que j'ai pas copié sur lui, m'sieur!)
>
>> Je pense pas, ca le fait au ping et aussi avec tftp
>> (client ras-de-terre de tftp-hpa-0.48:)
>
> D'après les essais que j'ai pû tenter, c'est assez général
> comme comportement. Je dois avoir des sources de noyau
> 2.2 qui trainent quelque part, je vais aller voir ce qu'il
Tu jettera un oeil au 0.99p155, pendant que t'es debout ?!?..
> en est au siècle dernier. Mais j'aimerais surtout comprendre
> le "pourquoi", la "motivation" du choix de ce comportement.
>
Plus je regarde le bout de code, plus je me dis: si y a truc qui
va pô, alors mettre un truc qui va bien à la place, fin-si.
Avec effet de bord, c'est 127.1 qui répond à 0.0.0.0, qui n'est pas
routable donc.
--
christophe.
Pascal Hambourg
> Eric Razny a écrit :
>
>> $ ping 0.0.0.0
>> PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
>
> Ca, c'est marrant.. Ton ping, il a déjà convertit
> INADDR_ANY en INADDR_LOOPBACK ?!
Le mien aussi. Sans regarder le code (de toute façon je n'y comprendrais
probablement rien, n'étant pas programmateur de sockets), je soupçonne
que ping affiche entre parenthèses l'adresse IP destination de la socket
raw créée, qui a été modifiée par le noyau.
> 0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
Une machine rapide, pour sûr. Sur la mienne c'est 0,200 ms.
Eric Razny
>>> $ ping 0.0.0.0
>>> PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
>>
>> Ca, c'est marrant.. Ton ping, il a déjà convertit
>> INADDR_ANY en INADDR_LOOPBACK ?!
>
> Le mien aussi. Sans regarder le code (de toute façon je n'y comprendrais
> probablement rien, n'étant pas programmateur de sockets), je soupçonne
> que ping affiche entre parenthèses l'adresse IP destination de la socket
> raw créée, qui a été modifiée par le noyau.
Je le pense aussi. Pour ce qui est des sources j'ai jeté un oeil (très)
rapide, mais il y a souvent des adressages indirects (comme "l'adresse
locale de la machine") et pas de référence explicite à INADDR_XXX ;
donc à moins de connaître il faut un coup de pot pour tomber là où il
faut, et je n'ai pas les capacités pour lancer un debug du noyau *et*
d'interpréter le résultat.
>
>> 0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
>
> Une machine rapide, pour sûr. Sur la mienne c'est 0,200 ms.
Tu as un vieux rossignol? Ma machine doit pourtant avoir 3 ans, mais à
l'époque je l'avais blindé "un peu" ; la prog en java[1] ça
bouffe plus de ressources qu'en C++ (IDE en particulier)
Le proc est un pentium 4 à 3.2GHz avec un cache de 2MB. Avec 1GB de Ram
de bonne facture je crois que je ne l'ai quasiment jamais vu swapper :)
Sur une machine core2duo à 1.86 Ghz j'ai moitié moins -0.023- (mais
c'est un serveur, pas une machine de dev ;) ).
--
Eric
[1] Ca fait des années que je n'ai rien codé de vraiment significatif en
C++, encore plus en C, alors aller chercher des trucs dans le noyau
ça me prend bien plus longtemps que quelqu'un qui n'est pas rouillé.
Pascal Hambourg
>
> Quant à un autre type de système entierement basé sur les fenêtres,
> il s'en rend bien compte, mais il essaye quand même:
>
> Pinging 0.0.0.0 with 32 bytes of data:
>
> Destination specified is invalid.
Ça doit dépendre des versions, parce que le mien (2000 SP4) me dit :
Hôte inconnu 0.0.0.0.
Ceci dit, il ne faut pas trop s'y fier car il répond la même chose pour
l'adresse de broadcast limité 255.255.255.255.
> 0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
> comme 255.255.255.255 (?)
Plaît-il ? 255.255.255.255 est une adresse destination parfaitement
valide, c'est l'adresse de broadcast limité.
>> Pascal, dans fcr.ip est arrivé au même
>> morceau de code <g0rk1p$1flu$1...@biggoron.nerim.net> avec une
>> conclusion qui me semble "presque" correcte.
>
> Tu aurais les refs' de l'article ? Je le trouve pas (meme au gougueule)
Auto-promo :
<http://groups.google.fr/group/fr.comp.reseaux.ip/msg/c36da1dc6d8297e1>
Dans le formulaire de recherche avancée, il faut retirer les <>
encadrant le message-id. C'est bizarre, mais c'est comme ça.
Quant au fait que tu ne le voies pas sur ton serveur de news, c'est
peut-être encore à cause de mon adresse source IPv6 qui serait vue comme
invalide par des filtres obsolètes. La chaîne de modération de
fr.comp.securite m'avait déjà fait le coup il y a quelques temps.
Regarde si tu vois d'autres articles récents de moi dans des forums non
modérés.
Pascal Hambourg
> Le Sat, 14 Jun 2008 19:25:27 +0000, Pascal Hambourg a écrit :
>
>>>Je pense plus à un problème de resolver sous nunux.
>>
>>Hypothèse intéressante, mais je crois que c'est xtof qui a raison, étant
>>arrivé à la même conclusion que lui.
>
> Il faudrait regarder dans les sources du noyau.
Justement, il me semble que le bout de code cité par xtof colle
parfaitement au comportement observé.
si destination est égale à 0 (0.0.0.0)
destination = source
si destination est encore égale à 0 (donc source non spécifiée)
destination = source = INADDR_LOOPBACK (127.0.0.1)
sachant qu'une adresse source à 0 signifie qu'elle n'est pas spécifiée
(INADDR_ANY), et que c'est le code de routage de sortie qui doit la
sélectionner parmi les adresses locales.
>>>$ ping 0.0.0.0
>>>PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
>>>64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms
>>>64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
>>
>>Qu'est-ce que c'est censé vérifier, au juste ?
>
> Effectivement ce n'est pas très probant au sens où on n'est quand même
> pas sur que c'est pas le noyau qui fait ça au lieu du resolver voire de
> ping.
Peut-être que le test que j'avais exposé dans fcr.ip te convaincra.
"ip route get <adresse>" permet d'évaluer le routage sortant pour une
adresse de destination donnée, éventuellement en spécifiant une adresse
source. ip ne fait manifestement pas de résolution de noms ou d'adresse
car on ne peut pas spécifier de nom à la place d'une adresse.
- Avec adresse source non spécifiée :
$ ip route get 0.0.0.0
local 127.0.0.1 dev lo src 127.0.0.1
local => route locale, interne à la machine
127.0.0.1 => adresse destination
dev lo => interface de sortie lo (loopback)
src 127.0.0.1 => adresse source sélectionnée
- Avec adresse source spécifiée (celle de eth0) :
$ ip route get 0.0.0.0 from 192.168.0.1
local 192.168.0.1 from 192.168.0.1 dev lo
Eric Razny
> Justement, il me semble que le bout de code cité par xtof colle
> parfaitement au comportement observé.
Quel con, j'ai zappé cette partie de son post!
> sachant qu'une adresse source à 0 signifie qu'elle n'est pas spécifiée
> (INADDR_ANY), et que c'est le code de routage de sortie qui doit la
> sélectionner parmi les adresses locales.
yep
> Peut-être que le test que j'avais exposé dans fcr.ip te convaincra.
> "ip route get <adresse>" permet d'évaluer le routage sortant pour une
> adresse de destination donnée, éventuellement en spécifiant une adresse
> source. ip ne fait manifestement pas de résolution de noms ou d'adresse
> car on ne peut pas spécifier de nom à la place d'une adresse.
>
> - Avec adresse source non spécifiée :
> $ ip route get 0.0.0.0
> local 127.0.0.1 dev lo src 127.0.0.1
Convaincu, le code indiqué par xtof est clair.
Pour le vérifier il suffit d'avoir du temps à perdre :
recompiler le noyau en remplaçant explicitement ici les adresses par
127.0.0.2 et en testant le résultat (et remettre un noyau clean, il doit
y avoir plein de gags à suivre à faire ce genre de modif)
Bon, pour la partie resolver je vais être mauvais joueur quand même :)
la partie du code pointée commence par :
==============
/*
* Major route resolver routine.
*/
static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp)
==============
Pascal Hambourg
> Le Mon, 16 Jun 2008 07:48:23 +0000, Pascal Hambourg a écrit :
>
>
>>>0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
>>
>>Une machine rapide, pour sûr. Sur la mienne c'est 0,200 ms.
>
> Tu as un vieux rossignol?
Tu dis pas du mal de ma Z-station avec son Pentium 233, stp ! C'est
largement suffisant pour ce qu'elle a à faire, et c'était la seule
machine en marche tournant sous GNU/Linux dans les parages au moment où
j'ai écrit ce message.
Pascal Hambourg
> Pascal Hambourg a fait rien qu'à écrire :
>
>> xtof.pernod a écrit :
>>>
>>> Quant à un autre type de système entierement basé sur les fenêtres,
>>> il s'en rend bien compte, mais il essaye quand même:
>>>
>>> Pinging 0.0.0.0 with 32 bytes of data:
>>> Destination specified is invalid.
>>
>> Ça doit dépendre des versions, parce que le mien (2000 SP4) me dit :
>> Hôte inconnu 0.0.0.0.
>
> Comme c'est pas une adresse numérique valide, il tente de la résoudre,
> et donc, le dns doit l'envoyer bouler, d'où adresse inconnue..
Je n'ai pas l'impression. Mon serveur DNS ne voit aucune requête pour le
nom "0.0.0.0". Par contre avec "ping -a 0.0.0.0" il reçoit une requête
PTR pour 0.0.0.0.in-addr.arpa, donc 0.0.0.0 est bien considéré comme une
adresse numérique.
Pascal Hambourg
> Pascal Hambourg a fait rien qu'à écrire :
>
>>>> Hôte inconnu 0.0.0.0.
>
> on arrive pas à résoudre
Oui, mais ce n'est pas logique. Je pense plutôt à un message foireux,
peut-être une erreur dans la traduction en français.