Le Tue, 10 Jun 2008 21:19:10 +0000, olivier.burelli a écrit***:

> 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

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

Eric Razny a écrit :
> 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.

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

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. 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 )

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

Le Mon, 16 Jun 2008 07:48:23 +0000, Pascal Hambourg 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.

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é.

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

Le Mon, 16 Jun 2008 19:38:43 +0000, Pascal Hambourg a écrit***:

> 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)
==============

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.