Les deux commentaires précedents étant moinsés, on en arrive de mille milliard de mouches mangent de la merde , elles ne peuvent pas se tromper... à la webcam fonctionne pas sous kopete ....
No comment :)
Mais il devient urgent d'ouvrir les commentaires négatifs sous peine de se retrouver .. totalement à la ramasse !
Mon commentaire perso ... je suis une mouche sur la merde .... argggghhh ... mais je mange bien merci ! des produits de qualités ! hahaha
486DX/33 (gros serveur HP de la bombe a l epoque :p)
p133 en 96 avec un win95 puis 98, premier essai a slack en 98 sur une partition de 80Mo
celeron 400 en 99 overclocke a 600 win98SE + diverses distrib
athlon 1.4 en 2002 slack
P2 266 (portable) en 2003 slack
Centrino 1.6 en 2004 slack
J'avoue m'y perdre... Plus je creuse plus je m'enfonce :) a la surface au moins ca a l'air sympa un traceroute !
Pout ta premiere remarque je suis d'accord c'est mathematique, j'ai beau chercher a te contredire je n'arrive pas a trouver la 'tite bete. Ca trotte ca trotte dans la tete mais faut que je me fasse une raison...
Je n'avais pas pense aux liens ATM c'est vrai...
J'espere tout de meme pouvoir resoudre mon probleme, si je peux !
En tout cas Markov c'est pas mon pote, comme tu dis c'est sacrement indigeste ! :)
Merci encore ca m'a tout de meme eclairci quelques points.
... sur ce c'est la fin de la journee j'va manger mon riz moi
Ok, je me suis mal fait comprendre dans le post precedent...
Les criteres de routage que fournissent les paquets (adresse de destination identique...) restent inchanges, je ne parle pas de ce que les protocoles de routage des equipements reseaux prennent en compte (charge reseau etc... ).
Ce que je voulais dire par la c'est que je doute qu'effectuer un traceroute sur les noeuds precedents soit d'un grand secours.
On ne cherche plus a joindre l'IP finale mais un intermediaire : le protocole de routage selectionnera certainement une route plus avantageuse car il ne se base plus sur le meme critere qu'est l'adresse de destination.
Je sais bien que tout ce "bordel" est dynamique mais dans ce cas comment expliquer qu'un traceroute avec plus d'essais a chaque valeur de TTL renvoie generalement des valeurs pour les memes noeuds, plutot que des valeurs pour des noeuds distincts ? ( ex : traceroute -q 50 host_ip )
C'est bien qu'a un instant donne l'etat du reseau ne varie pas enormement ? Il est clair que si je fais le test 2 heures apres rien ne me certifie que j'emprunterai le meme chemin (comme ce devrait etre le cas d'une seconde a l'autre mais l'experience montre bien que ce n'est pas le cas).
Si ce n'est pas le cas il s'agirait alors d'une erreur de la part de traceroute lorsqu'il retourne les resultats il n'affiche pas pour chaque temps de retour l'IP de l'equipement qui me retourne le signal ICMP "Time Exceed".
Pour ce qui est du choix du chemin je me doutais de la reponse mais je pensais qu'il devait etre possible de determiner un chemin prioritaire (je ne maitrise pas le reseau en cause donc je n'y peux rien...)
La raison de cette question est simple : j'ai constate que lorsque j'essaie d'acceder a des sites francais 2 chemins principaux se dessinent (il y en a d'autres bien sur), dont un qui passe par un equipement qui me perd 25% des paquets... Genre acces a linuxfr.org / fnac.com / equipe.fr extremement long, mais acces a liberation.fr / telecomlille.net tres rapide...
Si je pouvais reussir a eviter cet equipement ca serait a mon avis pas mal ...
Il me semblait pourtant que lorsqu'on effectue un traceroute l'adresse de destination ne change pas, c'est seulement le TTL qui est incremente, ce qui signifierait donc que pour le chemin aller les regles de routage ne devraient pas etre modifiees (sauf si la valeur du champ TTL est prise en compte...). Donc le chemin ne devrait pas etre significativement change si les conditions du reseau restent similaires pendant les quelques minutes que dure le traceroute...
Apres pour le chemin de retour je suis d'accord avec le fait qu'il puisse etre different car le noeud precedent a l aller ne sera pas forcement optimal au retour. C'est ce qui a mon sens pourrait expliquer la difference de temps.
Apres je me plante peut etre :)
Autre question dans le genre, est il possible de decider par soit meme du chemin que doivent prendre les paquets sur le grand Ternet ? J'en doute mais bon :) Si par magie ca existe je suis preneur ! (20% de paquets perdus en moyenne ce n'est pas acceptable ...)
Je ne suis pas l'admin du réseau en question, je n'ai pas le pouvoir de changer la config comme je le souhaiterais... Pour ce qui est de recevoir les pings, c'est justement pour éviter le flood, la connexion n'étant pas une bête de course... Pour ce qui est du ping depuis l'intérieur je me pose d'ailleurs la question sur la raison de ce choix :)
Mon problème vient plutôt d'autre chose, outre le fait de bloquer les ICMP echo et request, le fait de bloquer les autres types de messages ICMP peut-il être la cause de problèmes ? J'en vois un entre autre, notamment de devoir attendre le timeout du navigateur alors qu'un "destination unreachable" aurait certainement donné le même résultat mais plus vite. Si je me gourre n'hésitez pas à me le faire savoir !
Je vois une autre application a sa déclaration ...
Récupérer des ristournes auprès de Microsoft en arguant d'une politique pro-logiciel libre et d'un futur détournement des administrations pour les produits MS.
==> Ne pas oublier qu'il s'agit là d'économies et qu'il me semble un peu tôt pour dire que la philosophie du libre est un point que Mr Raffarin prend en compte. C'est avant tout une source d'économies. Et s'il peu grapiller de belles réductions il ne dira pas non. (Il n'y a pas seulement le coup des licences mais également les frais de formations, de migrations des services, de support ... etc).
Comme tu le disais l'effet d'annonce n'est pas anodin...
en 1998 avec un SVM offrant un joli linux kheops avec un kernel 2.0.36
150 pages de manuels imprimées en NB pour reussir a comprendre qqch ...
pourquoi ? simplement essayer...
puis une mandrake 5.0 et finalement apres avoir essayé tout ce qui pouvait passer par la main en terme de distrib (RH, Corel, LFS, ...) arret sur la slack :) aaaah
[^] # Re: Mouai
Posté par Viallet Vincent . En réponse au journal Windows Server 2003 plus fiable que Linux, selon le Yankee Group. Évalué à -3.
Les deux commentaires précedents étant moinsés, on en arrive de mille milliard de mouches mangent de la merde , elles ne peuvent pas se tromper... à la webcam fonctionne pas sous kopete ....
No comment :)
Mais il devient urgent d'ouvrir les commentaires négatifs sous peine de se retrouver .. totalement à la ramasse !
Mon commentaire perso ... je suis une mouche sur la merde .... argggghhh ... mais je mange bien merci ! des produits de qualités ! hahaha
# ma vie
Posté par Viallet Vincent . En réponse au sondage Mon ordinateur actuel est mon. Évalué à 1.
486DX/33 (gros serveur HP de la bombe a l epoque :p)
p133 en 96 avec un win95 puis 98, premier essai a slack en 98 sur une partition de 80Mo
celeron 400 en 99 overclocke a 600 win98SE + diverses distrib
athlon 1.4 en 2002 slack
P2 266 (portable) en 2003 slack
Centrino 1.6 en 2004 slack
le temps passe ....
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . En réponse au message analyse d'un traceroute. Évalué à 1.
c'est peut etre du bricolage mais je doute que ca agrave la situation vu ou on est ! (15s pour libe et 2min l'equipe)
merci
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . En réponse au message analyse d'un traceroute. Évalué à 1.
Merci bien pour toutes ces infos !
J'avoue m'y perdre... Plus je creuse plus je m'enfonce :) a la surface au moins ca a l'air sympa un traceroute !
Pout ta premiere remarque je suis d'accord c'est mathematique, j'ai beau chercher a te contredire je n'arrive pas a trouver la 'tite bete. Ca trotte ca trotte dans la tete mais faut que je me fasse une raison...
Je n'avais pas pense aux liens ATM c'est vrai...
J'espere tout de meme pouvoir resoudre mon probleme, si je peux !
En tout cas Markov c'est pas mon pote, comme tu dis c'est sacrement indigeste ! :)
Merci encore ca m'a tout de meme eclairci quelques points.
... sur ce c'est la fin de la journee j'va manger mon riz moi
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . En réponse au message analyse d'un traceroute. Évalué à 2.
Les criteres de routage que fournissent les paquets (adresse de destination identique...) restent inchanges, je ne parle pas de ce que les protocoles de routage des equipements reseaux prennent en compte (charge reseau etc... ).
Ce que je voulais dire par la c'est que je doute qu'effectuer un traceroute sur les noeuds precedents soit d'un grand secours.
On ne cherche plus a joindre l'IP finale mais un intermediaire : le protocole de routage selectionnera certainement une route plus avantageuse car il ne se base plus sur le meme critere qu'est l'adresse de destination.
Je sais bien que tout ce "bordel" est dynamique mais dans ce cas comment expliquer qu'un traceroute avec plus d'essais a chaque valeur de TTL renvoie generalement des valeurs pour les memes noeuds, plutot que des valeurs pour des noeuds distincts ? ( ex : traceroute -q 50 host_ip )
C'est bien qu'a un instant donne l'etat du reseau ne varie pas enormement ? Il est clair que si je fais le test 2 heures apres rien ne me certifie que j'emprunterai le meme chemin (comme ce devrait etre le cas d'une seconde a l'autre mais l'experience montre bien que ce n'est pas le cas).
Si ce n'est pas le cas il s'agirait alors d'une erreur de la part de traceroute lorsqu'il retourne les resultats il n'affiche pas pour chaque temps de retour l'IP de l'equipement qui me retourne le signal ICMP "Time Exceed".
Pour ce qui est du choix du chemin je me doutais de la reponse mais je pensais qu'il devait etre possible de determiner un chemin prioritaire (je ne maitrise pas le reseau en cause donc je n'y peux rien...)
La raison de cette question est simple : j'ai constate que lorsque j'essaie d'acceder a des sites francais 2 chemins principaux se dessinent (il y en a d'autres bien sur), dont un qui passe par un equipement qui me perd 25% des paquets... Genre acces a linuxfr.org / fnac.com / equipe.fr extremement long, mais acces a liberation.fr / telecomlille.net tres rapide...
Si je pouvais reussir a eviter cet equipement ca serait a mon avis pas mal ...
balou
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . En réponse au message analyse d'un traceroute. Évalué à 2.
Il me semblait pourtant que lorsqu'on effectue un traceroute l'adresse de destination ne change pas, c'est seulement le TTL qui est incremente, ce qui signifierait donc que pour le chemin aller les regles de routage ne devraient pas etre modifiees (sauf si la valeur du champ TTL est prise en compte...). Donc le chemin ne devrait pas etre significativement change si les conditions du reseau restent similaires pendant les quelques minutes que dure le traceroute...
Apres pour le chemin de retour je suis d'accord avec le fait qu'il puisse etre different car le noeud precedent a l aller ne sera pas forcement optimal au retour. C'est ce qui a mon sens pourrait expliquer la difference de temps.
Apres je me plante peut etre :)
Autre question dans le genre, est il possible de decider par soit meme du chemin que doivent prendre les paquets sur le grand Ternet ? J'en doute mais bon :) Si par magie ca existe je suis preneur ! (20% de paquets perdus en moyenne ce n'est pas acceptable ...)
[^] # Re: ahah ! :-)
Posté par Viallet Vincent . En réponse au journal salut(recherche de stage). Évalué à 3.
reste que deux journaux avec des fautes c'est un peu dommage tout de même ... comme s'il n'avait pas tenu compte des remarques la première fois ;)
bon allez ! bon courage quand même ! ça se trouve un stage, un peu de motivation et d'investissement et ça fait déjà beaucoup !
[^] # Re: Mwai
Posté par Viallet Vincent . En réponse au message gestion de firewall - interdire tout paquet ICMP. Évalué à 1.
Je ne suis pas l'admin du réseau en question, je n'ai pas le pouvoir de changer la config comme je le souhaiterais... Pour ce qui est de recevoir les pings, c'est justement pour éviter le flood, la connexion n'étant pas une bête de course... Pour ce qui est du ping depuis l'intérieur je me pose d'ailleurs la question sur la raison de ce choix :)
Mon problème vient plutôt d'autre chose, outre le fait de bloquer les ICMP echo et request, le fait de bloquer les autres types de messages ICMP peut-il être la cause de problèmes ? J'en vois un entre autre, notamment de devoir attendre le timeout du navigateur alors qu'un "destination unreachable" aurait certainement donné le même résultat mais plus vite. Si je me gourre n'hésitez pas à me le faire savoir !
balou [OverDaWorld]
[^] # Re: Bien entendu
Posté par Viallet Vincent . En réponse au journal Raffarin vante les logiciels libres comme source d'économie. Évalué à 5.
Récupérer des ristournes auprès de Microsoft en arguant d'une politique pro-logiciel libre et d'un futur détournement des administrations pour les produits MS.
==> Ne pas oublier qu'il s'agit là d'économies et qu'il me semble un peu tôt pour dire que la philosophie du libre est un point que Mr Raffarin prend en compte. C'est avant tout une source d'économies. Et s'il peu grapiller de belles réductions il ne dira pas non. (Il n'y a pas seulement le coup des licences mais également les frais de formations, de migrations des services, de support ... etc).
Comme tu le disais l'effet d'annonce n'est pas anodin...
[^] # Re: Benchez en java-script :D
Posté par Viallet Vincent . En réponse au journal Benchez en java-script :D. Évalué à 1.
ranking: 497 out of 502 testers
boarf :) pas mieux
# Re: Les chinois du FBI et l'IETF
Posté par Viallet Vincent . En réponse au journal Les chinois du FBI et l'IETF. Évalué à 4.
[^] # Re: Qu'écoutez-vous en cette période ?
Posté par Viallet Vincent . En réponse au journal Qu'écoutez-vous en cette période ?. Évalué à 1.
# Re: Mon premier système GNU/Linux
Posté par Viallet Vincent . En réponse au journal Mon premier système GNU/Linux. Évalué à 2.
en 1998 avec un SVM offrant un joli linux kheops avec un kernel 2.0.36
150 pages de manuels imprimées en NB pour reussir a comprendre qqch ...
pourquoi ? simplement essayer...
puis une mandrake 5.0 et finalement apres avoir essayé tout ce qui pouvait passer par la main en terme de distrib (RH, Corel, LFS, ...) arret sur la slack :) aaaah