Re: Aïe...
Félix Hauri a ecrit : >> "à venir") signale qu'un "arrêté fédéral >Pas trouvé, je n'ai rien trouvé concernant les brevets, n'as tu pas un >lien plus direct? Depuis la page http://www.admin.ch/ch/f/gg/pc/preview.html, charger le fichier PDF http://www.admin.ch/ch/f/gg/pc/franz.pdf, et voir sur la page 2, sous "Département fédéral de Justice et Police". La consultation est à venir, il n'y a pour l'instant pas plus d'infos que ce que j'ai écrit. >> Si quelqu'un est intéressé à suivre ce qui se passe, et à faire quelque >> chose, il est le bienvenu, comme toujours. D'après ce que j'ai compris, les >Je, mais j'espère n'être pas le seul;-) Ne pas compter sur moi sur ce coup là. Par contre, je pense prendre un peu de temps pour m'occuper de la modification de la loi sur les droits d'auteurs (càd l'introduction du DMCA américain en Suisse), cf http://www.ifpi.ch/F/jurinfo/j140.htm -- il y a aussi des infos sur les brevets sur cette page. Marc Mongenet était aussi intéressé à s'investir sur ce sujet. Daniel Cordey a écrit: >Nous devons tous nous manifester. Juste un mail a la confederation >aujourd'hui, un autre ailleur demain. Mais nosu devons TOUS le faire; avec >des arguments non emotifs, etayes, et economiques !!! Tout à fait d'accord. J'ai eu quelques échanges d'email avec des gens de l'IFPI (droit d'auteur) qui semblaient tout à fait réceptifs (ce qui ne veut pas dire qu'ils prendront en compte les commentaires, mais au moins, ils ne ferment pas la discussion, contrairement à l'impression que j'ai eue avec la Suisa). Je crois que Marc Schaefer avait aussi eu un bon contact. Frédéric -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Majuscules et Minuscules ... FTP depuis windows?
Dominique Muller wrote: > On Thu, 16 Aug 2001 13:18:38 %z (EDT) > [EMAIL PROTECTED] wrote: > > > Mais... Si quelqun connaît une astuce pour que windows cesse de déconner > > avec la casse, un tuyau serait bienvenu. Ma methode préferée dans ce cas, c'est de faire des archives tar.gz. (tar et gzip sont disponibles à travers CygWin par exemple). Peut-etre cela marche aussi avec WinZip. Mais bon, si tu n'as pas un acces shell sur le site où tu upload tes fichiers ce n'est pas une aide. Have fun Ivo -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
analyse réseau.
Bonjour, J'ai le problème suivant: Un cyber café d'une 40 aine de postes, connecté en adsl 2mb. Ils ont un serveur win2000. De temps en temps, il y a un ralentissement de la connection, voir blocage (durant 1 heure par exemple). Comment puis-je avoir plus d'info sur le problème? quels outils existe t'il sur linux pour analyser le réseau? Je peux essayer de me mettre directement à la sortie du modem pour voir quelque chose? ps: la ligne est fournie par Sunrise.. peut-être que quelqu'un de vous est au courant qu'ils ont des problèmes (durant ces deux dernières semaines) Ils disent que non, mais bon.. on ne sait jamais avec les boîtes... Merci pour vos idées. -- Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
HP OfficeJet support under Linux
Bonne nouvelle concernant les OfficeJet (All-In-One) d'HP. Les choses commencent a bouger (enfin !), et c'est un type d'HP qui semble avoir repris le projet. Donc, toutes les informations relatives aux support/developpement des drivers des imprimantes Officejet d'HP se trouvent sur le site : http://hpoj.sourceforge.net En allant sur la page : http://www.sourceforge.net/suplist.shtml Vous trouverez la liste des imprimantes supportees avec leurs focntionalites. On y decouvre que certaines imprimantes/scanners sont maintenant supportees en USB, le lient vers les drivers (fournis par HP !) appropries, etc. La derniere version du driver est la 0.8. Je l'installerai ce week-end (si j'en ai le temps) sur mon systeme ayant une distrib SuSe 7.2 (kernel 2.4.5). Je vous tiendrai au courant de mes eventuelles difficultes. Le site n'est pas tres grand mais il est tres complet. Entre autre, toutes les isnstructions d'installations, desinstallations, compilations, explications de l'usage de certaisn directory dans les RPM, autres liens, etc. Un must pour tout pocesseur (ou en attente de l'etre) d'OfficeJet ! Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Aïe...
On Fri, Aug 17, 2001 at 01:25:49PM +0200, Frederic Schutz wrote: > Félix Hauri a ecrit : > > >> "à venir") signale qu'un "arrêté fédéral > >Pas trouvé, je n'ai rien trouvé concernant les brevets, n'as tu pas un > >lien plus direct? > > Depuis la page http://www.admin.ch/ch/f/gg/pc/preview.html, charger le > fichier PDF http://www.admin.ch/ch/f/gg/pc/franz.pdf, et voir sur la page > 2, sous "Département fédéral de Justice et Police". La consultation est à > venir, il n'y a pour l'instant pas plus d'infos que ce que j'ai écrit. > > >> Si quelqu'un est intéressé à suivre ce qui se passe, et à faire quelque > >> chose, il est le bienvenu, comme toujours. D'après ce que j'ai compris, les > >Je, mais j'espère n'être pas le seul;-) ca m'interesse beaucoup aussi, meme si je suis simplement contre le brevet pour les logiciels (le droit d'auteur suffit) j'ai bien envie de me pencher sur le sujet, je vais commencet a gentiment me documenter. par contre faux que humm je fasse un ratrapage en terme de procedure civique, j'y connais pas gd chose :)) > Ne pas compter sur moi sur ce coup là. Par contre, je pense prendre un peu > de temps pour m'occuper de la modification de la loi sur les droits > d'auteurs (càd l'introduction du DMCA américain en Suisse), cf > http://www.ifpi.ch/F/jurinfo/j140.htm -- il y a aussi des infos sur les > brevets sur cette page. Marc Mongenet était aussi intéressé à s'investir > sur ce sujet. -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
On Fri, Aug 17, 2001 at 03:21:43PM +0200, Yann Sagon wrote: > De temps en temps, il y a un ralentissement de la connection, voir blocage > (durant 1 heure par exemple). > > Comment puis-je avoir plus d'info sur le problème? > > quels outils existe t'il sur linux pour analyser le réseau? > > Je peux essayer de me mettre directement à la sortie du modem pour voir > quelque chose? Tu peux utiliser un simple sniffer comme tcpdump ou sniffit connecté directement sur le LAN (s'il n'est pas switché). Sinon il existe aussi des programmes plus haut-niveau comme etherape qui permet de voir quelles machines produisent le plus de trafic. > ps: la ligne est fournie par Sunrise.. peut-être que quelqu'un de vous est au > courant qu'ils ont des problèmes (durant ces deux dernières semaines) > Ils disent que non, mais bon.. on ne sait jamais avec les boîtes... Tu peux mettre en place sur ce réseau mrtg pour voir la gueule du trafic et tu peux aussi grapher le round-trip time jusqu'à la gateway pour voir s'il s'agit d'un problème sur la ligne. -- Francois Deppierraz <[EMAIL PROTECTED]> Nimag Networks Sàrl - www.nimag.net PGP Key ID: 9D283BC9 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
On Fri, Aug 17, 2001 at 03:21:43PM +0200, Yann Sagon wrote: > Bonjour, > > J'ai le problème suivant: > Un cyber café d'une 40 aine de postes, connecté en adsl 2mb. > Ils ont un serveur win2000. > > De temps en temps, il y a un ralentissement de la connection, voir blocage > (durant 1 heure par exemple). > > Comment puis-je avoir plus d'info sur le problème? oula c vague comme probleme! ce cyber-cafe connait-il au moins l'utilisation de son lien ADSL? j'entend, font-ils des statistique de l'utilisation de traffic au travers du lien? c'est indispensable en premiere analyse. a cet fin il existe MRTG par exemple, mais le provider devrait aussi pouvoir fournir ces stats. > quels outils existe t'il sur linux pour analyser le réseau? ping tcpdump traceroute mais il faut trouver quoi pinger, il faut bien connaitre TCP/IP pour lire les log de tcpdump, il faut interpreter finement une serie de traceroute. bref, le trouble-shooting de reseau et tres difficilement automatisable. si le modem ADSL ne comporte aucune fonction de routage, la premiere chose a faire est de pinguer pendant un bon moment l'adresse de passerelle donnee par l'isp au client. la passerelle est aussi apelee 'default gateway' 'default router' 'next-hop router' par les isp. le ping envoyant un paquet de test chaque seconde, l'idee est de verifier que le lien ADSL ne soit pas la cause de perte de paquet par erreur de transmission. exemple chez moi: philou@philou:~$ ping -c 100 195.202.200.30 64 bytes from 195.202.200.30: icmp_seq=96 ttl=64 time=56.073 msec 64 bytes from 195.202.200.30: icmp_seq=97 ttl=64 time=54.078 msec 64 bytes from 195.202.200.30: icmp_seq=98 ttl=64 time=54.983 msec 64 bytes from 195.202.200.30: icmp_seq=99 ttl=64 time=55.678 msec --- 195.202.200.30 ping statistics --- 100 packets transmitted, 97 packets received, 3% packet loss round-trip min/avg/max/mdev = 23.694/49.700/131.892/11.938 ms 195.202.200.30 est ma passerelle, donnee fourni par mon isp:) apres 100 ping, 3 ont ete perdu. 3%, c'est normal sur un lien telereseau. sur un lien DSL, c'est deja anormal. mais il faut s'assurer qu'il n'y ait pas de traffic autre que le ping durant un test de ce genre, il suffit que pendant ce temps, l'utilisation du lien soit moyenne a forte, et il devient naturelle, normal, de voir un taux de paquet perdu de quelques pourcents. l'utilisation de trame ethernet de taille max (1514 bytes) avec la commande ping -s 1472 ... est tres utile pour trouver des bizarreries. > Je peux essayer de me mettre directement à la sortie du modem pour voir > quelque chose? > > ps: la ligne est fournie par Sunrise.. peut-être que quelqu'un de vous est au > courant qu'ils ont des problèmes (durant ces deux dernières semaines) > Ils disent que non, mais bon.. on ne sait jamais avec les boîtes... aucune idee. -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
On Fri, 17 Aug 2001, Philippe Strauss wrote: > ping tcpdump traceroute Tu peux aussi inclure 'bing' (different de ping), qui donne des informatiosn plus detaillees en fonction de la taille des paquets transmis. C'est parfois tres utile pour determiner un probleme de congestion d'un router particulier en fonction de la taille de certains paquest. See 'man bing' Aussi, j'effectue parfois un ping sur chaque router lister par traceroute. Ca permet de cerner le lieu... Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
> > Tu peux utiliser un simple sniffer comme tcpdump ou sniffit connecté > directement sur le LAN (s'il n'est pas switché). Sinon il existe aussi > des programmes plus haut-niveau comme etherape qui permet de voir > quelles machines produisent le plus de trafic. > Que veut dire "pas switché", pas relié à un switch? > Tu peux mettre en place sur ce réseau mrtg pour voir la gueule du trafic Oui, mrtg me parait être une bonne idée, par contre, il faut connaître le mot de passe du routeur pour avoir accès à la lecture, non? Malheureusement, je doute qu'ils le connaissent. c'est un sisco 1600. > et tu peux aussi grapher le round-trip time jusqu'à la gateway pour voir > s'il s'agit d'un problème sur la ligne. MRTG le fait aussi? -- Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
> oula c vague comme probleme! > Oui! > ce cyber-cafe connait-il au moins l'utilisation de son lien ADSL? > j'entend, font-ils des statistique de l'utilisation de traffic au travers > du lien? c'est indispensable en premiere analyse. > En fait, je ne sais pas trop, ils utilisent windows2000 et je ne connais pas bien. Et j'ai l'impression qu'ils n'ont pas de techniciens. > a cet fin il existe MRTG par exemple, mais le provider devrait > aussi pouvoir fournir ces stats. > Oui, je pense que je vais voir avec ça. > > si le modem ADSL ne comporte aucune fonction de routage, C'est un cisco 1600, il fait aussi routeur. la premiere > chose a faire est de pinguer pendant un bon moment l'adresse de passerelle > donnee par l'isp au client. > la passerelle est aussi apelee 'default gateway' 'default router' 'next-hop > router' par les isp. Je veux bien, mais je pense qu'elle est configurée dans le routeur, encore faut-il que le provider me la donne.. > > le ping envoyant un paquet de test chaque seconde, l'idee est de verifier > que le lien ADSL ne soit pas la cause de perte de paquet par erreur > de transmission. > L'incovenient est que le problème de liaison est épisodique.. et je ne compte pas rester devant le pc toute la journée.! De plus, si sunrise ne veut pas donner la passerelle, y a t'il un moyen de la trouver? (en supposant bien sûr que je n'ai pas le mot de passe du routeur!) > > mais il faut s'assurer qu'il n'y ait pas de traffic autre que le ping > durant un test de ce genre, il suffit que pendant ce temps, l'utilisation Va falloir que je vienne la nuit:) > > l'utilisation de trame ethernet de taille max (1514 bytes) avec la commande > ping -s 1472 ... est tres utile pour trouver des bizarreries. > Pourquoi? les grands paquets ont plus de chance d'être perdus? > > Je peux essayer de me mettre directement à la sortie du modem pour voir > > quelque chose? > > Mon idée était de mettre un pc directement à la sortie du modem routeur car le problème peut aussi venir de leur serveur. Autrement, le modem, les switches sont dans un endroit mal ventilé. Est-ce que ça peut éventuellement provoquer un tel problème? -- Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
Tiens, je viens de penser à un truc: est ce que code red pourrait ralentir un tel routeur? > c'est un sisco 1600. > -- Yann Sagon -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
On Fri, Aug 17, 2001 at 08:08:04PM +0200, Yann Sagon wrote: > Tiens, je viens de penser à un truc: > est ce que code red pourrait ralentir un tel routeur? > > > c'est un sisco 1600. Ah alors c pas la paserrelle mais plus loin, le noeud suivant, qu'il faudrai pinger, mais oui, codered, sur un 1600, selon la taille de l'espace d'adressage sur le port ethernet du routeur, peut pedaler dans la choucroute grace a la qualite exceptionelle de l'implementation d'ARP chez cisco.. arrives-tu a obtenir comme info, le masque configure sur le port ethernet (LAN) du 1600? je pense que deja une classe C sur un 1600 pourrait pauser des problemes a son ARP depuis codered A+ -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
> Je veux bien, mais je pense qu'elle est configurée dans le routeur, encore > faut-il que le provider me la donne.. elle est configuree sur les machines, si il n'y a pas encore une translation d'adresse dans le 1600! a part ca, foutre un lien de 2Mbit/s sur un 1600.. c plutot leger, le CPU sera vite mechament entame!! > L'incovenient est que le problème de liaison est épisodique.. et je ne compte > pas rester devant le pc toute la journée.! ok, l'idee est de compare les taux de paquet perdu entre les moment ou ca marche bien et ceux ou ca rame, il y a un script ping qqchose livre avec mrtg, dans le repertoire contrib ou qqchose comme ca. > De plus, si sunrise ne veut pas donner la passerelle, y a t'il un moyen de la > trouver? (en supposant bien sûr que je n'ai pas le mot de passe du routeur!) oui, traceroute! > > mais il faut s'assurer qu'il n'y ait pas de traffic autre que le ping > > durant un test de ce genre, il suffit que pendant ce temps, l'utilisation > > Va falloir que je vienne la nuit:) non mais simplement s'assurer sur les graph mrtg, que tu n'est pas dans un moment un peu chaud mais plutot calme au niveau du debit :) > > l'utilisation de trame ethernet de taille max (1514 bytes) avec la commande > > ping -s 1472 ... est tres utile pour trouver des bizarreries. > > > Pourquoi? les grands paquets ont plus de chance d'être perdus? oui, mais aussi c comme ca que du detecte les cas de MTU trop petite, l'ADSL de swiscom utilise du PPPoverEthernet ou un truc comme ca qui diminue de qques bytes la MTU, la taille maximale d'un paquet au niveau IP. a+ -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
Yann Sagon <[EMAIL PROTECTED]> writes: > > Tu peux utiliser un simple sniffer comme tcpdump ou sniffit connecté > > directement sur le LAN (s'il n'est pas switché). Sinon il existe aussi > > des programmes plus haut-niveau comme etherape qui permet de voir > > quelles machines produisent le plus de trafic. > > > Que veut dire "pas switché", pas relié à un switch? c'est ca. en switcher tu ne pourras voir que ce qui passe sur le port du switch que tu observes, donc les broadcasts ainsi que le traffic genere par ton analyseur et le traffic destine a celui-ci. alors que sur un port non switcher (donc un port d'un hub), tu verras le traffic de chaque port du hub. tom -- as seen in a signature: "In an open world without walls and fences, who needs Gates and windows?" -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Spam encore !
At 16.08.01 08'43, you wrote: Hello ! > > Je ne suis absolument pas d'accord ! Il y a même TROIS raisons pour > > que ce mail passe sous SPAM chez moi ! > > > > Raison 1 : "save up to" > > Raison 2 : la mention d'un pourcentage (bon ça c'est un peu extrême) > > mais surtout : > > Raison 3 : "Life Insurance" > > Rien que la raison 3 t'aurait enlevé ce SPAM :-)) > >Je comprends to approche. Dans notre cas, nous travaillons avec des >institutions (societes financiere, assurances, banques...) et certains nous >posent leurs question, ou nous communiquent leurs problemes, en utilisant le >mail. Il n'est donc pas rare de recevoir des messages dont le sujet est : > > - Problem with "xxx Life Insurance" > - Symbol CKRZ divided by 75% > - How could I save images ? > - ... Ca ne dérange en rien, tous les deux jours je regarde mon répertoire SPAM afin de trier et je n'efface que les vrais SPAM, c'est vraiment exceptionnel de trouver un message par erreur dedans... >Et puis, que reponds-tu a aux administrateurs des systemes a la Zurich, la >Balaoise, SwissLife", etc. ? Comment ça ? >Ta methode est correcte mais elle un peu trop radicale dans certains >environements de business. Ce qui est valable pour l'office du tourisme de >Champignac ne l'est pas forcement pour l'UBS, ou d'autres. Pour cela je suis entièrement d'accord Denis -- Denis Bucher, / [EMAIL PROTECTED] Tél. +41-22-8000625 \ Internet Horus Networks / horus-networks.comFax: +41-22-8000622 \ Services / USA: (206) 888-2335 US Fax: (508) 437-1261 \ Provider -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Majuscules et Minuscules ... FTP depuis windows?
At 16.08.01 15'18, [EMAIL PROTECTED] wrote: >Bon. J'utilise un petit logiciel sympathique, ws_ftp, et lorsque je >commence le transfert, je réalise que la casse n'est pas repectée. Je n'ai jamais constaté d'erreurs de ce genre avec WS_FTP ! Je crois que le problème c'est Windows : C'est lorsque tes fichiers passent par Windows qu'il y a un problème, pour éviter cela je confirme les autres messsages : Faire des archives. Cela parfois peut même garder les protections des fichiers, etc... Soit en zip soit en tgz... Denis -- Denis Bucher, / [EMAIL PROTECTED] Tél. +41-22-8000625 \ Internet Horus Networks / horus-networks.comFax: +41-22-8000622 \ Services / USA: (206) 888-2335 US Fax: (508) 437-1261 \ Provider -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
On Fri, Aug 17, 2001 at 07:48:22PM +0200, Yann Sagon wrote: > > Tu peux utiliser un simple sniffer comme tcpdump ou sniffit connecté > > directement sur le LAN (s'il n'est pas switché). Sinon il existe aussi > > des programmes plus haut-niveau comme etherape qui permet de voir > > quelles machines produisent le plus de trafic. > > > Que veut dire "pas switché", pas relié à un switch? Oui, cela veut dire que tu arrives à intercepter tout le trafic sur le LAN. D'ailleurs c'est aussi possible avec un switch en configurant un port en Roving Analysis (terminologie 3com), c'est à dire qu'un certain port peut aussi recevoir le trafic destiné à un ou plusieurs autres ports. > > Tu peux mettre en place sur ce réseau mrtg pour voir la gueule du trafic > > Oui, mrtg me parait être une bonne idée, par contre, il faut connaître le mot > de passe du routeur pour avoir accès à la lecture, non? Il faut connaître la communauté SNMP, tu peux essayer public qui est celle par défaut mais je ne pense que c'est activé par défaut. Sinon il va falloir configurer l'accès SNMP sur le routeur lui-même et pour ça y'a besoin du mot de passe. Donc soit tu demandes gentiment à sunrise soit tu essaies de trouver un trou dans IOS te permettant d'accéder à la config (Philou ?). Peut-être même que c'est possible de récupérer la mémoire flash qui contient IOS et la config afin de modifier celle-ci à partir d'un PC ? > > et tu peux aussi grapher le round-trip time jusqu'à la gateway pour voir > > s'il s'agit d'un problème sur la ligne. > > MRTG le fait aussi? En magouillant un peu, ouais. -- Francois Deppierraz <[EMAIL PROTECTED]> Nimag Networks Sàrl - www.nimag.net PGP Key ID: 9D283BC9 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: analyse réseau.
On Fri, 17 Aug 2001 19:58:38 +0200 Yann Sagon <[EMAIL PROTECTED]> écrivait: > > si le modem ADSL ne comporte aucune fonction de routage, > C'est un cisco 1600, il fait aussi routeur. Salut... Tiens c'est la première fois que je vois un cisco 1600 avec une interface Adsl intégrée. Ce qui me parrait bizarre c'est de l'Adsl à 2 MB/s, peut-être que ton ISP offre lui-même cette prestation. Mais une chose qui est certaine si ta connexion est bien de l'Adsl (avec un A), c'est que le modem adsl (même intégré au routeur) transporte les paquets IP dans des cellules ATM avec le DSLAM qui lui fait une connexion ATM sur un switch. Si la liaison ATM est unique entre le modem et le DSLAM, elle est multiple entre le DSLAM et le switch, donc il peut y avoir de la congession à cet endroit, normalement ça ne devrait pas, mais certains providers peu scrupuleux essayent toujours de tirer partie au maximum d'un support de transmission. Normalement dans ce cas, ça laisse des trace sur les systèmes de surveillence des équipements ATM et ton ISP peut contrôler. Si ton routeur a une interface Hdsl (avec un H), la technique est très différente et s'apparente à une connxion série avec modem utilisant une interface V35 ou X21. Dans ce cas, la transmission ne se fait pas en ATM. C'est une liaison symétrique entre 64 et 2048 KB/s et les routeurs y montent directement de l'IP dessus. La topologie est nettement plus simple. Une chose à observer, c'est la longueur de la ligne entre les 2 modems. Selon la section du cuivre et le nombre de paires (2 ou 4) la distance max peut varier entre 1 et 5 Km. Si le pop de ton ISP se trouve dans le même quatier, il ne devrait pas y avoir de problème, sinon tu peux vérifier quand il y a du bloquage si le modem est en alarme. S'il est intégré au routeur, en général il y a une led allumée quand la liaison est "up". Adsl ou Hdsl, tu peux alors essayer de faire un traceroute pour connaitre la topologie du réseau, si tu as la chance que ton ISP ne bloque pas les paquets icmp. Si c'est le cas, quand c'est congessionné, essaye de faire des pings sur les adresses des routeurs obtennues par le traceroute et examine les temps de réponse. Si icmp est bloqué, alors il faut demander à l'ISP les adresses des passerelles. > Je veux bien, mais je pense qu'elle est configurée dans le routeur, encore > faut-il que le provider me la donne.. Ca dépend en éffait du sérieux de ton ISP à aider à lever un dérangement ;-/ > L'incovenient est que le problème de liaison est épisodique.. et je ne compte > pas rester devant le pc toute la journée.! Tu peux toujours mettre un PC linux à côté des 20 machines (donc derrière le serveur) et faire un ping chaque minute (cron) sur chaque élément de réseau et reporter le résultat dans un fichier. Exemple: ping -c 1 premier.routeur.isp.ch >> fichier.log ping -c 1 deuxième.routeur.isp.ch >> fichier.log ou plus simplement si ça passe: traceroute www.ton_isp.ch >> fichier.log bon, il y a peut être plus élégant :-) > De plus, si sunrise ne veut pas donner la passerelle, y a t'il un moyen de la > trouver? (en supposant bien sûr que je n'ai pas le mot de passe du routeur!) traceroute normalement, cf plus haut. > > l'utilisation de trame ethernet de taille max (1514 bytes) avec la commande > > ping -s 1472 ... est tres utile pour trouver des bizarreries. > > > Pourquoi? les grands paquets ont plus de chance d'être perdus? On peut voir s'il y a fragmentation je suppose. Si les paquets IP passent dans des cellules ATM, ça peut démontrer des choses intéressentes en éffait, surtout en cas de congession de cellules. (cellules perdues). > Mon idée était de mettre un pc directement à la sortie du modem routeur car > le problème peut aussi venir de leur serveur. Avec 2 cartes ethernet, tu peux aussi insérer un pc linux entre le routeur et le serveur qui forwarde tout le trafic d'une carte à l'autre et analyser ce qu'il se passe quand il y a congession. (avec tcpdump, sniffit, etc). > Autrement, le modem, les switches sont dans un endroit mal ventilé. Est-ce > que ça peut éventuellement provoquer un tel problème? Je sais pas pour un cisco 1600, mais les gros routeurs comme 7200, 12000, etc. font une surveillence de température avec 2 états, le premier donne une alarme, le second éffectue un shutdown du routeur. Normalement il redémarre quand la température interne du routeur à baissé suffisament. (à vérifier sur le site de Cisco). Si les éléments sont stackés les uns sur les autres, essaye de les alligner verticalement les uns à côté des autres, la circulation d'air est bien meilleure, faire circuler un peut d'air même chaud avec un ventilateur, c'est très efficace et en plus, tu améliores nettement la durée de vie des équipements. Désolé, pas de solution, juste des idées (un peut couteau suisse, c'est vrais...), résoudre un problème sporadique c'est pas évident. Ah bon, tu l'as remarqué aussi ? :-) Bonnes chances... Dom. -- E-mail: [EMAIL PROTECTED]
Re: analyse réseau.
On Fri, Aug 17, 2001 at 07:58:38PM +0200, Yann Sagon wrote: > > chose a faire est de pinguer pendant un bon moment l'adresse de passerelle > > donnee par l'isp au client. > > la passerelle est aussi apelee 'default gateway' 'default router' 'next-hop > > router' par les isp. > > Je veux bien, mais je pense qu'elle est configurée dans le routeur, encore > faut-il que le provider me la donne.. Normalement un simple traceroute te permettra de connaître le next hop. > De plus, si sunrise ne veut pas donner la passerelle, y a t'il un moyen de la > trouver? (en supposant bien sûr que je n'ai pas le mot de passe du routeur!) Normalement ils devraient quand même pouvoir vous donner le mot de passe pour accéder au routeur en read-only. Pour le enable on peut comprendre qu'ils soient pas très chauds... > > l'utilisation de trame ethernet de taille max (1514 bytes) avec la commande > > ping -s 1472 ... est tres utile pour trouver des bizarreries. > > > Pourquoi? les grands paquets ont plus de chance d'être perdus? Suivant les cas tu peux avoir des problèmes de tunnels bizarres style ip over ip qui font baisser le MTU et ça peut provoquer la perte des paquets trop gros. Style quand le serveur (ou un routeur intermédiaire) bloque l'ICMP et qu'il peut pas renvoyer un message "paquet trop gros" alors que le bit DF (Do not fragment) était mis. > Autrement, le modem, les switches sont dans un endroit mal ventilé. Est-ce > que ça peut éventuellement provoquer un tel problème? Je pense qu'il faut vraiment qu'il fasse très chaud pour que ça pose ce genre de problèmes. -- Francois Deppierraz <[EMAIL PROTECTED]> Nimag Networks Sàrl - www.nimag.net PGP Key ID: 9D283BC9 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
