Bonjour les spécialistes. Ma question est simple, et voici une
démonstration évidente de mes doutes...
-------------------------------------------
:~$ uname -a
Linux gally 2.6.12-10-686 #1 Wed Feb 7 03:56:37 UTC 2007 i686 GNU/Linux
:~$ 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
-------------------------------------------
~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
~ $ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
telnet: connect to address 0.0.0.0: Invalid argument
~ $ 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 "lynxhttp://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 :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Bonjour les spécialistes. Ma question est simple, et voici une
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 "lynxhttp://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 : moderateurs-fc...@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Bonjour les spécialistes. Ma question est simple, et voici une
démonstration évidente de mes doutes...
-------------------------------------------
:~$ uname -a
Linux gally 2.6.12-10-686 #1 Wed Feb 7 03:56:37 UTC 2007 i686 GNU/Linux
:~$ 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
-------------------------------------------
~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
~ $ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
telnet: connect to address 0.0.0.0: Invalid argument
~ $ 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 "lynxhttp://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 :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
> On May 19, 9:25 am, "Thierry B." wrote:(...)
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.
J'aimerais bien savoir si ce comportement est normal, dangereux,
justifié, toussa. Et où le trouver dans les sources de la kernelle.
Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
--> telnet dans ton cas.
> On May 19, 9:25 am, "Thierry B." <t...@prout.stex.invalid> wrote:
(...)
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.
J'aimerais bien savoir si ce comportement est normal, dangereux,
justifié, toussa. Et où le trouver dans les sources de la kernelle.
Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
--> telnet dans ton cas.
> On May 19, 9:25 am, "Thierry B." wrote:(...)
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.
J'aimerais bien savoir si ce comportement est normal, dangereux,
justifié, toussa. Et où le trouver dans les sources de la kernelle.
Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
--> telnet dans ton cas.
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.
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.
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.
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 =)
Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)
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 =)
Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)
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 =)
Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)
Je pense plus à un problème de resolver sous nunux.
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 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
Je pense plus à un problème de resolver sous nunux.
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 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
Je pense plus à un problème de resolver sous nunux.
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 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
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.
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
hth.
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.
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
hth.
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.
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
hth.
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 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
Qu'est-ce que c'est censé vérifier, au juste ?
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 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
Qu'est-ce que c'est censé vérifier, au juste ?
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 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms
Qu'est-ce que c'est censé vérifier, au juste ?
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 ?
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$ 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.
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 ?
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.
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 ?
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$ 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.
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 ?!
0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
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 ?!
0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
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 ?!
0.053 ms pour router sur le loopback ? T'as quoi comme machine ?
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.
0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
comme 255.255.255.255 (?)
Pascal, dans fcr.ip est arrivé au même
morceau de code <g0rk1p$1flu$ avec une
conclusion qui me semble "presque" correcte.
Tu aurais les refs' de l'article ? Je le trouve pas (meme au gougueule)
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.
0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
comme 255.255.255.255 (?)
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)
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.
0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
comme 255.255.255.255 (?)
Pascal, dans fcr.ip est arrivé au même
morceau de code <g0rk1p$1flu$ avec une
conclusion qui me semble "presque" correcte.
Tu aurais les refs' de l'article ? Je le trouve pas (meme au gougueule)