Re: [HS] lenteur sur internet, modification de MTU ?

[Charles Plessy <charles-debian-nospam@plessy.org>]

Le Sat, Oct 27, 2007 at 05:02:04PM +0200, Pascal Hambourg a écrit :
> 
> torg, c'est une machine à l'extérieur de ton réseau ?

> >La où je ne comprends plus rien, c'est que 220.157.247.254 c'est
> >l'adresse IP de mon routeur, mais 192.168.1.5 ça n'est pas lui, c'est la
> >borne Airport qui est *derrière*.
> 
> Ce ne serait pas plutôt - par coïncidence - l'adresse privée de torg, la 
> machine à partir de laquelle tu fais l'essai ?

> sorbet, c'est une machine de ton réseau local ?

Bonjour Pascal, et d'abords merci pour toutes les réponses.

Effectivement, sorbet est une machine de mon réseau local, située
derrière ma borne airport, dont l'IP privée est comme par hasard la même
que celle de torg, machine extérieure à mon réseau, ce qui m'avait
enduit d'erreur.

Résumons:

Depuis torg (extérieur), j'essaye de joindre kunpuu (mon routeur). Les
paquets de moins de 1427 octets passent sans fragmentation, et pour les
autres, si le drapeau DF vaut 1, torg reçoit un message de
ksgnim4.asahi-net.or.jp, que je soupçonne être mon modem ou une machine
juste derrière. En effet, la route pour l'internet mondial depuis kunpuu
(mon routeur) est :
211.13.152.16 dev ppp0  proto kernel  scope link src 220.157.247.254

Si je fais le même test depuis torg (extérieur) vers d'autres serveurs,
j'obtiens des valeurs différentes : MTU de 1500-28 = 1472 pour
www.debian.org (comme ça c'est moins hors sujet ;) ou pour
postman.riken.jp (on va y revenir).

Voyons maintenant depuis sorbet, ma machine à l'intérieur qui me pose problème
(ainsi que toutes les autres en fait) si je ne baisse pas la MTU à la main à
1412 (ce qui est ennuyeux quand j'ai des invités utilisant d'autres systèmes
d'exploitation, car dans ce cas, je ne sais pas le faire). Quand je ne précise
pas la MTU, celle-ci se positionne automatiquement à 1500. En faisant le test
plus haut, je mesure la MTU à 1426, pour torg (charles.plessy.org, maintenant à
l'extérieur), www.debian.org ou postman.riken.jp. Donc si j'ai bien compris,
les paquets ICMP circulent bien, car s'il y avait un trou noir je devrais
perdre la réponse.

Mais dans ce cas, je n'arrive pas à m'expliquer pourquoi j'arrive à relever ma
boîte IMAP chez postman.riken.jp quand je limite la MTU à 1412 (nombre
déterminé au pifomètre dans le passé, je suppose qu'avec 1426 cela marcherait
aussi ?), alors que si je laisse la machine libre de choisir la valeur (1500),
j'obtiens un superbe timeout, capturé ci-dessous.

      1 0.000000    192.168.0.3           192.168.0.1           DNS      Standard query AAAA postman.riken.jp
      2 0.015040    192.168.0.1           192.168.0.3           DNS      Standard query response
      3 0.059465    192.168.0.3           192.168.0.1           DNS      Standard query AAAA postman.riken.jp.igloo
      4 0.062249    192.168.0.1           192.168.0.3           DNS      Standard query response, No such name
      5 0.062372    192.168.0.3           192.168.0.1           DNS      Standard query A postman.riken.jp
      6 0.063313    192.168.0.1           192.168.0.3           DNS      Standard query response A 134.160.33.2
      7 0.064934    192.168.0.3           134.160.33.2          TCP      49302 > imaps [SYN] Seq=0 Len=0 MSS=1460 TSV=72899 TSER=0 WS=7
      8 0.078895    134.160.33.2          192.168.0.3           TCP      imaps > 49302 [SYN, ACK] Seq=0 Ack=1 Win=23168 Len=0 MSS=1460 TSV=518652272 TSER=72899 WS=2
      9 0.078967    192.168.0.3           134.160.33.2          TCP      49302 > imaps [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=72903 TSER=518652272
     10 0.079725    192.168.0.3           134.160.33.2          SSLv2    Client Hello
     11 0.094310    134.160.33.2          192.168.0.3           TCP      imaps > 49302 [ACK] Seq=1 Ack=106 Win=5792 Len=0 TSV=518652287 TSER=72903
     12 0.098629    134.160.33.2          192.168.0.3           SSL      [TCP Previous segment lost] Continuation Data
     13 0.098690    192.168.0.3           134.160.33.2          TCP      [TCP Dup ACK 10#1] 49302 > imaps [ACK] Seq=106 Ack=1 Win=5888 Len=0 TSV=72908 TSER=518652287 SLE=1449 SRE=1922
     14 5.014024    ViaTechn_d4:0a:b5     AppleCom_2b:be:04     ARP      Who has 192.168.0.3?  Tell 192.168.0.1
     15 5.014069    AppleCom_2b:be:04     ViaTechn_d4:0a:b5     ARP      192.168.0.3 is at 00:11:24:2b:be:04


Le problème rencontré ici, je le rappelle, n'est pas spécifique à l'IMAP.
J'observe aussi le même phénomène avec des sites webs, surtout des webmails ou
des sites de commerce en ligne, pour lesquels j'ai du mal à faire des tests car
premièrement ils bloquent les pings, et deuxièmement les blocages
n'apparaissent que dans certaines conditions que je ne peux pas reproduire
moi-même, en particulier pour les webmails dans lesquels je n'ai pas de compte
(mais mes invités en ont, c'est comme ça que j'avais découvert ce problème).


Bon dimanche,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan