Re: Probleme de connexion Ethernet - WAS Re: installation de msttcorefonts
Bernard <bdebreil@teaser.fr> writes:
> Sylvain Sauvage wrote:
>> [Pas de CC: merci. C’est la règle sur les listes Debian : celui
>> qui en veut le demande.]
>>
>
> Je reçois les messages de cette liste via Thunderbird (Icedove) et,
> avec cet outil, si je fais un "reply all", çà inclue automatiquement
> ton adresse perso dans la liste des destinataires. Et si je fais un
> "reply" tout court, c'est ton adresse perso qui s'affiche. Je vais
> donc m'efforcer, dorénavant, d'effacer ton adresse perso de mes 'reply
> all', mais ne t'étonne pas si d'autres personnes t'envoient des cc,
> car c'est apparemment ce qui se passe par défaut.
>
> Merci de voir plus bas :
>> Bernard, dimanche 6 septembre 2009, 22:08:56 CEST
>>
>>> […]
>>> --2009-09-06 21:58:47--
>>> http://surfnet.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
>>> Résolution de surfnet.dl.sourceforge.net... échec: Connexion
>>> terminée par expiration du délai d'attente.
>>> wget: unable to resolve host address `surfnet.dl.sourceforge.net'
>>> […]
>>> Voilà. Je puis sauvegarder une à une chacune des polices concernées
>>> (j'en ai vu une liste dans le site cité par Christophe), mais par
>>> le processus automatique : pas moyen jusqu'ici.
>>>
>>> S'agissant d'un package hyper courant, je m'étonne qu'il n'y ait
>>> pas davantage de remontées sur ce problème.
>>>
>>
>> Oui, c’est étrange.
>>
>> Dans le script, wget est lancé avec les options suivantes :
>> --dns-timeout=10 --connect-timeout=5 --read-timeout=300
>> (Ce sont des secondes.)
>>
>> Par défaut, dns-timeout et connect-timeout n’ont pas de valeur
>> et ce sont donc les délais « habituels » qui sont utilisés.
>> C’est 5 secondes pour resolv.conf avant d’essayer le DNS
>> suivant. Donc ça fait ~10 s si on en a 2 (comme c’est souvent le
>> cas). Donc ça devrait être équivalent… enfin, essaie-les dans un
>> shell. Si ça coince aussi, c’est que ces délais sont trop
>> courts. Modifie alors le script en conséquence.
>>
>
> Pas encore testé, mais tes remarques m'amènent à me poser d'autres
> questions et, en quelque sorte, çà me met une puce à l'oreille. Il se
> pourrait bien que j'aie un problème de DNS ou autre problème de
> connexion. En effet, depuis que je suis passé de Sarge à Lenny, c'est
> à dire, depuis le 26 août, il se trouve que, justement, mes temps de
> connexion sont très longs. Sur le web, via Firefox alias Iceweasel, si
> j'ouvre un site, çà prend facilement 20 secondes voire plus avant que
> de le récupérer, alors que c'était autrefois quasiment
> instantané. J'ignorais pourquoi et je pensais que cela avait quelque
> chose à voir avec les dysfonctionnements actuels chez Orange ADSL (mon
> débit est aussi divisé par deux... mais çà, c'est sans doute autre
> chose, car je constate la même anomalie sur mon portable connecté en
> WiFi sur la même Livebox).
>
> Mon fichier /etc/host contient ceci :
>
> 127.0.0.1 localhost
> 127.0.1.1 new-host.home new-host
>
> # The following lines are desirable for IPv6 capable hosts
> ::1 localhost ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> ff02::3 ip6-allhosts
>
> Voilà. Sur mon portable sous Ubuntu 8.04, il n'y a pas davantage, et
> même moins, puisque les lignes for IPv6 capable hosts sont
> absentes. Quant à /etc/resolv.conf :
>
> ### BEGIN INFO
> #
> # Modified_by: NetworkManager
> # Process: /usr/bin/NetworkManager
> # Process_id: 2968
> #
> ### END INFO
>
> domain home
>
>
> search home
>
>
> nameserver 192.168.1.1
>
> le numéro de mon serveur de nom est donc celui de ma Livebox ! Mais
> je trouve la même chose sur mon portable sous Ubuntu !
>
> Peut-être devrais-je ajouter l'adresse du nameserver de mon
> fournisseur d'accès, teaser.fr ou orange.fr ?
>
> Il y a également autre chose qui m'inquiète. J'ai DEUX cartes Ethernet
> ! Pourquoi 2 ? Eh bien, lorsque j'ai acheté ce PC en décembre 2006
> (sans système d'exploitation), il comprenait une carte mère ASUS
> P5LD2SE incluant LAN:- RTL8111B PCI-E Gb LAN controller. Lorsque, dès
> la livraison de l'appareil, j'ai voulu procéder à l'installation de
> Debian Sarge, la carte Ethernet n'était pas reconnue ! Alors j'ai
> branché, à tout hazard, une autre carte qui provenait d'un vieux PC de
> mon collègue... Celle ci étant reconnue tout de suite, je ne me suis
> pas posé d'autres questions et ai procédé à l'installation. Ceci a
> fonctionné ainsi jusqu'au 26 août 2009, date de mon installation de
> Lenny en lieu et place de Sarge. A l'install de Lenny, deux cartes
> Ethernet étaient désormais reconnues ! J'ai opté pour la première,
> celle qui était sélectionnée par défaut, et l'installation a paru se
> dérouler normalement. Il se pourrait donc que, maintenant qu'il y a
> deux cartes Ethernet reconnues sur mon système, cela pose quelque
> problème... et puisse expliquer les délais de connexion et autres
> anomalies (le débit diminué de moitié, ce que j'attribuais aux
> problèmes techniques d'Orange.fr)
>
> Aujourd'hui, lorsque je fais
>
> lspci
>
> j'ai notamment ceci :
>
> ..................................
> ..................................
> 01:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
> (rev 74)
> 01:01.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
> [Envy24] PCI Multi-Channel I/O Controller (rev 02)
> 01:02.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
> 02:00.0 Ethernet controller: Realtek Semiconductor Co.,
> Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> ...............................................
>
> donc 2 Ethernet controllers, un '3Com' 3c905C-TX/TX-M [Tornado] et un
> Realtech PCI Express Gigabit Ethernet controller. Je ne sais même pas
> exactement celui qui est en service : comment le savoir ? Peut-être
> aurais-je avantage à débrancher celui qui avait été rajouté en
> décembre 2006 ?
~$ /sbin/ifconfig
Tu ne verras que les cartes effectivement en service.
Pour résoudre les problèmes réseau, rien ne vaut l'écoute sur les
ports ethernet. L'outil ultime pour ça, c'est wireshark.
Il te faudra un peu de persévérance pour comprendre ce que tu verras ;
quasiment tous les protocoles sont décodés et ça facilite largement
l'analyse, mais quelques rudiment de réseau sont quand même
nécessaires.
Tu peux aussi tester différents protocoles pour détecter celui qui
pose problème :
dig : permet de faire de la résolution DNS
telnet : permet d'établir une connection TCP (port 80 pour une
connection HTTP)
Exemple de test possible :
~$ dig www.debian.fr
....
;; ANSWER SECTION:
www.debian.fr. 86400 IN A 193.43.210.197
~$ telnet 193.43.210.197 80
Trying 193.43.210.197...
Connected to 193.43.210.197.
--
Léo.
Reply to: