(le FW: Spoof from Internet: est de moi, l'adresse IP de destination
correspond à l'adresse de mon interface ppp0).
Des comme ça, j'en ai pleins mes logs et ça dure depuis... ben depuis
que je me suis décidé à logguer, c'est-à-dire 10 jours.
Pensant à un problème de mon linux, j'ai sniffé ppp0 et même eth1 (où
transite la session PPPoE) et je retrouve bien ces paquets, donc ils
semblent bien venir des profondeurs du net.
J'ai vérifié ce qui sort de chez moi, nada, que neni, le vide.
Le plus fort : même après avoir changé d'IP, ça revient toujours.
Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur
le net ?
Je suis en ADSL chez Club-Internet, kernel 2.4.20.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
esus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
| Bonjour | | Je me suis décidé à monter un peu le niveau de sécurité | de mon firewall et logguer un peu plus ce qu'il se | retrouve bloqué. | | Quelle ne fut pas ma surprise de découvrir ceci : | | FW: Spoof from Internet: IN=ppp0 OUT= MAC= SRC7.0.0.1 | DST!2.195.191.1 LEN@ TOS=0x00 PREC=0x00 TTL6 ID 988 PROTO=TCP | TTL6 ID 988 PROTO=TCP SPT DPT96 WINDOW=0 RES=0x00 ACK RST | URGP=0
J'ai le même genre de trace aussi bien sous Linux que Win98/SE
| (le FW: Spoof from Internet: est de moi, l'adresse IP de destination | correspond à l'adresse de mon interface ppp0).
Idem "martians sources" comme certains le disent.
| | Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur | le net ?
Ce type de paquets sont très fréqents depuis un an environ et avec des adresses IP différentes de celle qui m'est allouée par mon FAI
| | Je suis en ADSL chez Club-Internet, kernel 2.4.20.
Je n'ai pas de certitude technique, mais les tests que j'ai pu faire m'indiquent que ce type de packets "ACK" (acquittement) sans paquet à acquitter (donc invalides) viennent en partie de mon propre modem ADSL.
En RTC je ne voyais rien de comparable. .
Compte tenu que la montée en puissance de ce type de paquets (toutes origines confondues) suit celle de la montée en puissance des accès ADSL, je suis tenté d'en conclure que nombres de modem ADSL sont buggés ou mal configurés.
Donc, à priori, rien d'inquiétant sauf qu'avec tout ce "bruit" il va devenir très difficile d'identifier une vraie tenative de "spoof" pour un non professionel.
- -- «Quand tu dors, es-tu un corps, une âme ou un repaire de sensations?» Taliesin, barde gallois (V-VI siècles) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
| Bonjour
|
| Je me suis décidé à monter un peu le niveau de sécurité
| de mon firewall et logguer un peu plus ce qu'il se
| retrouve bloqué.
|
| Quelle ne fut pas ma surprise de découvrir ceci :
|
| FW: Spoof from Internet: IN=ppp0 OUT= MAC= SRC7.0.0.1
| DST!2.195.191.1 LEN@ TOS=0x00 PREC=0x00 TTL6 ID 988 PROTO=TCP
| TTL6 ID 988 PROTO=TCP SPT DPT96 WINDOW=0 RES=0x00 ACK RST
| URGP=0
J'ai le même genre de trace aussi bien sous Linux que Win98/SE
| (le FW: Spoof from Internet: est de moi, l'adresse IP de destination
| correspond à l'adresse de mon interface ppp0).
Idem "martians sources" comme certains le disent.
|
| Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur
| le net ?
Ce type de paquets sont très fréqents depuis un an environ et avec des
adresses IP différentes de celle qui m'est allouée par mon FAI
|
| Je suis en ADSL chez Club-Internet, kernel 2.4.20.
Je n'ai pas de certitude technique, mais les tests que j'ai pu faire
m'indiquent que ce type de packets "ACK" (acquittement) sans paquet à
acquitter (donc invalides) viennent en partie de mon propre modem ADSL.
En RTC je ne voyais rien de comparable.
.
Compte tenu que la montée en puissance de ce type de paquets (toutes
origines confondues) suit celle de la montée en puissance des accès
ADSL, je suis tenté d'en conclure que nombres de modem ADSL sont buggés
ou mal configurés.
Donc, à priori, rien d'inquiétant sauf qu'avec tout ce "bruit" il va
devenir très difficile d'identifier une vraie tenative de "spoof" pour
un non professionel.
- --
«Quand tu dors, es-tu un corps, une âme ou un repaire de sensations?»
Taliesin, barde gallois (V-VI siècles)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
| Bonjour | | Je me suis décidé à monter un peu le niveau de sécurité | de mon firewall et logguer un peu plus ce qu'il se | retrouve bloqué. | | Quelle ne fut pas ma surprise de découvrir ceci : | | FW: Spoof from Internet: IN=ppp0 OUT= MAC= SRC7.0.0.1 | DST!2.195.191.1 LEN@ TOS=0x00 PREC=0x00 TTL6 ID 988 PROTO=TCP | TTL6 ID 988 PROTO=TCP SPT DPT96 WINDOW=0 RES=0x00 ACK RST | URGP=0
J'ai le même genre de trace aussi bien sous Linux que Win98/SE
| (le FW: Spoof from Internet: est de moi, l'adresse IP de destination | correspond à l'adresse de mon interface ppp0).
Idem "martians sources" comme certains le disent.
| | Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur | le net ?
Ce type de paquets sont très fréqents depuis un an environ et avec des adresses IP différentes de celle qui m'est allouée par mon FAI
| | Je suis en ADSL chez Club-Internet, kernel 2.4.20.
Je n'ai pas de certitude technique, mais les tests que j'ai pu faire m'indiquent que ce type de packets "ACK" (acquittement) sans paquet à acquitter (donc invalides) viennent en partie de mon propre modem ADSL.
En RTC je ne voyais rien de comparable. .
Compte tenu que la montée en puissance de ce type de paquets (toutes origines confondues) suit celle de la montée en puissance des accès ADSL, je suis tenté d'en conclure que nombres de modem ADSL sont buggés ou mal configurés.
Donc, à priori, rien d'inquiétant sauf qu'avec tout ce "bruit" il va devenir très difficile d'identifier une vraie tenative de "spoof" pour un non professionel.
- -- «Quand tu dors, es-tu un corps, une âme ou un repaire de sensations?» Taliesin, barde gallois (V-VI siècles) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur le net ?
C'est un effet de bord causé par Blaster. Pour éviter le DOS sur windowspdate.com certaines personnes ou certains "providers" ont fait que la resolution du nom windowsupdate.com renvoi 127.0.0.1. Or la machine infectée essaye de se contacter sur le port 80 en spoofant l'adresse source. Quand la connection est impossible, la machine répond à l'adresse spoofée avec un paquet RST...
Bad Max wrote:
Bonjour
Bonsoir,
Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur
le net ?
C'est un effet de bord causé par Blaster.
Pour éviter le DOS sur windowspdate.com certaines personnes ou certains
"providers" ont fait que la resolution du nom windowsupdate.com renvoi
127.0.0.1. Or la machine infectée essaye de se contacter sur le port 80
en spoofant l'adresse source. Quand la connection est impossible, la
machine répond à l'adresse spoofée avec un paquet RST...
Bref : y'a-t-il un virus où une attaque d'actualité en ce moment sur le net ?
C'est un effet de bord causé par Blaster. Pour éviter le DOS sur windowspdate.com certaines personnes ou certains "providers" ont fait que la resolution du nom windowsupdate.com renvoi 127.0.0.1. Or la machine infectée essaye de se contacter sur le port 80 en spoofant l'adresse source. Quand la connection est impossible, la machine répond à l'adresse spoofée avec un paquet RST...
Cependant les paquets en question continuent à être droppé par une autre règle du firewall et à aucun moment je ne vois apparaitre "warning martians source" ou autre message permettant d'avoir la confirmation que le rp_filter a fonctionné.
Qq a t'il une idée ??
Nicolas
esus wrote:
Idem "martians sources" comme certains le disent.
A propos des martians sources, j'ai aussi des paquet TCP en provenance
de 127.0.0.1:80 :
J'ai bien activé le rp_filter et le log_martians :
Cependant les paquets en question continuent à être droppé par une autre
règle du firewall et à aucun moment je ne vois apparaitre "warning
martians source" ou autre message permettant d'avoir la confirmation que
le rp_filter a fonctionné.
Cependant les paquets en question continuent à être droppé par une autre règle du firewall et à aucun moment je ne vois apparaitre "warning martians source" ou autre message permettant d'avoir la confirmation que le rp_filter a fonctionné.
Qq a t'il une idée ??
Nicolas
Bad Max
'lut,
Manu a écrit:
C'est un effet de bord causé par Blaster. Pour éviter le DOS sur windowspdate.com certaines personnes ou certains "providers" ont fait que la resolution du nom windowsupdate.com renvoi 127.0.0.1. Or la machine infectée essaye de se contacter sur le port 80 en spoofant l'adresse source. Quand la connection est impossible, la machine répond à l'adresse spoofée avec un paquet RST...
J'ai effectivement pu retrouver la même explication via google (suffisait de mettre la bonne combinaison de mots-clés).
Ce qui est inquiétant, c'est la fréquence : toutes les 15 à 20s. Et encore, il semble que ça commence à baisser, j'ai mesuré jusqu'à 1 paquet toutes les 5s (les utilisateurs de Club Int seraient-ils plus infectés que les autres ?).
Merci pour la confirmation.
Bad Max
'lut,
Manu a écrit:
C'est un effet de bord causé par Blaster.
Pour éviter le DOS sur windowspdate.com certaines personnes ou certains
"providers" ont fait que la resolution du nom windowsupdate.com renvoi
127.0.0.1. Or la machine infectée essaye de se contacter sur le port 80
en spoofant l'adresse source. Quand la connection est impossible, la
machine répond à l'adresse spoofée avec un paquet RST...
J'ai effectivement pu retrouver la même explication via google
(suffisait de mettre la bonne combinaison de mots-clés).
Ce qui est inquiétant, c'est la fréquence : toutes les 15 à 20s. Et
encore, il semble que ça commence à baisser, j'ai mesuré jusqu'à 1
paquet toutes les 5s (les utilisateurs de Club Int seraient-ils plus
infectés que les autres ?).
C'est un effet de bord causé par Blaster. Pour éviter le DOS sur windowspdate.com certaines personnes ou certains "providers" ont fait que la resolution du nom windowsupdate.com renvoi 127.0.0.1. Or la machine infectée essaye de se contacter sur le port 80 en spoofant l'adresse source. Quand la connection est impossible, la machine répond à l'adresse spoofée avec un paquet RST...
J'ai effectivement pu retrouver la même explication via google (suffisait de mettre la bonne combinaison de mots-clés).
Ce qui est inquiétant, c'est la fréquence : toutes les 15 à 20s. Et encore, il semble que ça commence à baisser, j'ai mesuré jusqu'à 1 paquet toutes les 5s (les utilisateurs de Club Int seraient-ils plus infectés que les autres ?).
Merci pour la confirmation.
Bad Max
Manu
Bad Max wrote:
Ce qui est inquiétant, c'est la fréquence : toutes les 15 à 20s. Et encore, il semble que ça commence à baisser, j'ai mesuré jusqu'à 1 paquet toutes les 5s (les utilisateurs de Club Int seraient-ils plus infectés que les autres ?).
Non je ne pense pas, chez Free et selon l'adresse qui t'es attribuée j'avais à peu près la même période (aux pires moments). Si ton FAI à décier de "combattre" lui-même le problème en ajoutant la correspondance 127.0.0.1 <=> windowsupdate.com dans ses serveurs DNS cela peut augmenter le nombre de paquets spoofés. Les personnes n'ayant pas fait la bonne manip pour éradiquer Blaster de leur machine génère des paquets spoofés, les autres infectés pouvant générés des paquets spoofés grâce à la résolution DNS citée avant.
Pour beaucoup, je pense que ces paquets viennent effectivement des abonnées du FAI, car en regardant le TTL des paquets on peut voir que la majorité ont des TTL de 125 à 127 (chez moi biensûr). Sachant que par défaut Windows génère des paquets avec un TTL de 128... Je ne sais pas trop comment considérer les paquets avec des TTL plus petits.
Bad Max wrote:
Ce qui est inquiétant, c'est la fréquence : toutes les 15 à 20s. Et
encore, il semble que ça commence à baisser, j'ai mesuré jusqu'à 1
paquet toutes les 5s (les utilisateurs de Club Int seraient-ils plus
infectés que les autres ?).
Non je ne pense pas, chez Free et selon l'adresse qui t'es attribuée
j'avais à peu près la même période (aux pires moments).
Si ton FAI à décier de "combattre" lui-même le problème en ajoutant la
correspondance 127.0.0.1 <=> windowsupdate.com dans ses serveurs DNS
cela peut augmenter le nombre de paquets spoofés. Les personnes n'ayant
pas fait la bonne manip pour éradiquer Blaster de leur machine génère
des paquets spoofés, les autres infectés pouvant générés des paquets
spoofés grâce à la résolution DNS citée avant.
Pour beaucoup, je pense que ces paquets viennent effectivement des
abonnées du FAI, car en regardant le TTL des paquets on peut voir que la
majorité ont des TTL de 125 à 127 (chez moi biensûr). Sachant que par
défaut Windows génère des paquets avec un TTL de 128...
Je ne sais pas trop comment considérer les paquets avec des TTL plus petits.
Ce qui est inquiétant, c'est la fréquence : toutes les 15 à 20s. Et encore, il semble que ça commence à baisser, j'ai mesuré jusqu'à 1 paquet toutes les 5s (les utilisateurs de Club Int seraient-ils plus infectés que les autres ?).
Non je ne pense pas, chez Free et selon l'adresse qui t'es attribuée j'avais à peu près la même période (aux pires moments). Si ton FAI à décier de "combattre" lui-même le problème en ajoutant la correspondance 127.0.0.1 <=> windowsupdate.com dans ses serveurs DNS cela peut augmenter le nombre de paquets spoofés. Les personnes n'ayant pas fait la bonne manip pour éradiquer Blaster de leur machine génère des paquets spoofés, les autres infectés pouvant générés des paquets spoofés grâce à la résolution DNS citée avant.
Pour beaucoup, je pense que ces paquets viennent effectivement des abonnées du FAI, car en regardant le TTL des paquets on peut voir que la majorité ont des TTL de 125 à 127 (chez moi biensûr). Sachant que par défaut Windows génère des paquets avec un TTL de 128... Je ne sais pas trop comment considérer les paquets avec des TTL plus petits.
C'est quoi ce :2 à la fin ? Ou plutôt, si 2 est la valeur fourni à rp_filter qu'est ce que cela signifie ?
Cependant les paquets en question continuent à être droppé par une autre règle du firewall et à aucun moment je ne vois apparaitre "warning martians source" ou autre message permettant d'avoir la confirmation que le rp_filter a fonctionné.
On en revient à mon post du 20/12/2003, où je n'avais pas eu de réponse. Ma conclusion avait été : "J'ai activé log_martians et rp_filter mais je n'ai aucune trace dans mes logs des paquets 127.0.0.1:80. Si je crois bien comprendre, log_martians ne log pas les paquets car ils ont une destination correct d'un point de vue routage mais rp_filter rejette ces paquets car un paquet de source 127.0.0.1 ne doit ne peut provenir que de l'interface locale (lo)." log_martians vérifie le routage par rapport à la destination et l'interface d'entrée. rp_filter vérifie le routage par rapport à la source et l'interface d'entrée.
En plaçant des règles en prerouting on voit bien les paquets passer, mais ils semblent arriver nullepart. Donc pour moi ils sont rejetés par rp_filter.
C'est quoi ce :2 à la fin ?
Ou plutôt, si 2 est la valeur fourni à rp_filter qu'est ce que cela
signifie ?
Cependant les paquets en question continuent à être droppé par une autre
règle du firewall et à aucun moment je ne vois apparaitre "warning
martians source" ou autre message permettant d'avoir la confirmation que
le rp_filter a fonctionné.
On en revient à mon post du 20/12/2003, où je n'avais pas eu de réponse.
Ma conclusion avait été :
"J'ai activé log_martians et rp_filter mais je n'ai aucune trace dans
mes logs des paquets 127.0.0.1:80. Si je crois bien comprendre,
log_martians ne log pas les paquets car ils ont une destination correct
d'un point de vue routage mais rp_filter rejette ces paquets car un
paquet de source 127.0.0.1 ne doit ne peut provenir que de l'interface
locale (lo)."
log_martians vérifie le routage par rapport à la destination et
l'interface d'entrée.
rp_filter vérifie le routage par rapport à la source et l'interface
d'entrée.
En plaçant des règles en prerouting on voit bien les paquets passer,
mais ils semblent arriver nullepart. Donc pour moi ils sont rejetés par
rp_filter.
C'est quoi ce :2 à la fin ? Ou plutôt, si 2 est la valeur fourni à rp_filter qu'est ce que cela signifie ?
Cependant les paquets en question continuent à être droppé par une autre règle du firewall et à aucun moment je ne vois apparaitre "warning martians source" ou autre message permettant d'avoir la confirmation que le rp_filter a fonctionné.
On en revient à mon post du 20/12/2003, où je n'avais pas eu de réponse. Ma conclusion avait été : "J'ai activé log_martians et rp_filter mais je n'ai aucune trace dans mes logs des paquets 127.0.0.1:80. Si je crois bien comprendre, log_martians ne log pas les paquets car ils ont une destination correct d'un point de vue routage mais rp_filter rejette ces paquets car un paquet de source 127.0.0.1 ne doit ne peut provenir que de l'interface locale (lo)." log_martians vérifie le routage par rapport à la destination et l'interface d'entrée. rp_filter vérifie le routage par rapport à la source et l'interface d'entrée.
En plaçant des règles en prerouting on voit bien les paquets passer, mais ils semblent arriver nullepart. Donc pour moi ils sont rejetés par rp_filter.
PsyKotroP
Bad Max wrote:
Bonjour
Je me suis décidé à monter un peu le niveau de sécurité de mon firewall et logguer un peu plus ce qu'il se retrouve bloqué.
Um ca ressemble tres tres fort à un emule ou kazaa installé sur le PC en local. Je vous rapelle que ce genre de petite crotte de programme vous positionne un web serveur local pour le sharing files et son administration !
-- PoSe|dOn-
Bad Max wrote:
Bonjour
Je me suis décidé à monter un peu le niveau de sécurité
de mon firewall et logguer un peu plus ce qu'il se
retrouve bloqué.
Um ca ressemble tres tres fort à un emule ou kazaa installé sur le PC en
local. Je vous rapelle que ce genre de petite crotte de programme vous
positionne un web serveur local pour le sharing files et son administration
!
Um ca ressemble tres tres fort à un emule ou kazaa installé sur le PC en local. Je vous rapelle que ce genre de petite crotte de programme vous positionne un web serveur local pour le sharing files et son administration !
C'est quoi ce :2 à la fin ? Ou plutôt, si 2 est la valeur fourni à rp_filter qu'est ce que cela signifie ?
C'est bien la valeur qui est mise dans le pseudo-fichier rp_filter de chaque interface.
J'avais mit 1 à l'origine dedans mais comme j'avais vu que certaines distrib le mettait à 2 et que rp_filter à 1 ne semblait pas arreter les 127.0.0.1:80 j'avais essayé de changer la valeur en 2. J'ai fait mon copier/coller pour le post sans faire gaffe avant de la remettre à 1 . Ca ne change manifestement pas grand chose au problème, parce que avec 1 ou avec 2 ca donne la même chose.
C'est quoi ce :2 à la fin ?
Ou plutôt, si 2 est la valeur fourni à rp_filter qu'est ce que cela
signifie ?
C'est bien la valeur qui est mise dans le pseudo-fichier rp_filter de
chaque interface.
J'avais mit 1 à l'origine dedans mais comme j'avais vu que certaines
distrib le mettait à 2 et que rp_filter à 1 ne semblait pas arreter les
127.0.0.1:80 j'avais essayé de changer la valeur en 2. J'ai fait mon
copier/coller pour le post sans faire gaffe avant de la remettre à 1 .
Ca ne change manifestement pas grand chose au problème, parce que avec 1
ou avec 2 ca donne la même chose.
C'est quoi ce :2 à la fin ? Ou plutôt, si 2 est la valeur fourni à rp_filter qu'est ce que cela signifie ?
C'est bien la valeur qui est mise dans le pseudo-fichier rp_filter de chaque interface.
J'avais mit 1 à l'origine dedans mais comme j'avais vu que certaines distrib le mettait à 2 et que rp_filter à 1 ne semblait pas arreter les 127.0.0.1:80 j'avais essayé de changer la valeur en 2. J'ai fait mon copier/coller pour le post sans faire gaffe avant de la remettre à 1 . Ca ne change manifestement pas grand chose au problème, parce que avec 1 ou avec 2 ca donne la même chose.
Nicolas
Cedric Blancher
Dans sa prose, Nicolas GIMMILLARO nous ecrivait :
J'avais mit 1 à l'origine dedans mais comme j'avais vu que certaines distrib le mettait à 2 et que rp_filter à 1 ne semblait pas arreter les 127.0.0.1:80 j'avais essayé de changer la valeur en 2. J'ai fait mon copier/coller pour le post sans faire gaffe avant de la remettre à 1 . Ca ne change manifestement pas grand chose au problème, parce que avec 1 ou avec 2 ca donne la même chose.
Ça apparaît en effet dans certaines documentations. Toujours est-il que sous les 2.4, c'est une valeur booléenne. C'est désactivé si c'est à 0, activer pour tout autre valeur positive. Donc, 1, 2 ou 3445, c'est pareil.
C'était peut-être différent avec les 2.2, mais je n'ai pas été voir le code.
-- Debout, face au mur et les paluches en l'air... que j'les vois bien. On est charge a la magnum. Si vous bougez seulement les oreilles, on vous coupe par le milieu. -+- Bernard Blier, Faut pas prendre les enfants du Bon Dieu...
Dans sa prose, Nicolas GIMMILLARO nous ecrivait :
J'avais mit 1 à l'origine dedans mais comme j'avais vu que certaines
distrib le mettait à 2 et que rp_filter à 1 ne semblait pas arreter les
127.0.0.1:80 j'avais essayé de changer la valeur en 2. J'ai fait mon
copier/coller pour le post sans faire gaffe avant de la remettre à 1 . Ca
ne change manifestement pas grand chose au problème, parce que avec 1 ou
avec 2 ca donne la même chose.
Ça apparaît en effet dans certaines documentations. Toujours est-il que
sous les 2.4, c'est une valeur booléenne. C'est désactivé si c'est à
0, activer pour tout autre valeur positive. Donc, 1, 2 ou 3445, c'est
pareil.
C'était peut-être différent avec les 2.2, mais je n'ai pas été voir
le code.
--
Debout, face au mur et les paluches en l'air... que j'les vois bien.
On est charge a la magnum. Si vous bougez seulement les oreilles, on vous
coupe par le milieu.
-+- Bernard Blier, Faut pas prendre les enfants du Bon Dieu...
J'avais mit 1 à l'origine dedans mais comme j'avais vu que certaines distrib le mettait à 2 et que rp_filter à 1 ne semblait pas arreter les 127.0.0.1:80 j'avais essayé de changer la valeur en 2. J'ai fait mon copier/coller pour le post sans faire gaffe avant de la remettre à 1 . Ca ne change manifestement pas grand chose au problème, parce que avec 1 ou avec 2 ca donne la même chose.
Ça apparaît en effet dans certaines documentations. Toujours est-il que sous les 2.4, c'est une valeur booléenne. C'est désactivé si c'est à 0, activer pour tout autre valeur positive. Donc, 1, 2 ou 3445, c'est pareil.
C'était peut-être différent avec les 2.2, mais je n'ai pas été voir le code.
-- Debout, face au mur et les paluches en l'air... que j'les vois bien. On est charge a la magnum. Si vous bougez seulement les oreilles, on vous coupe par le milieu. -+- Bernard Blier, Faut pas prendre les enfants du Bon Dieu...
