[TCP] Problème de résolution TCP. (résolu)

[Soulou]

Bonjours à tous,

J'ai un petit problème concernant la résolution de mes connexions vers certains serveurs, des exemples tout d'abord :
- Impossible de me connecter à MSN via Pidgin (Erreur de lecture), mais depuis amsn, pas de soucis.
- De nombreux site très très lents, parmis eux : facebook.com, ent.unistra.fr (site de mon université).

Des problèmes certe, mineurs, mais particulièrement génant. J'ai d'abord pensé à un problème des serveurs DNS de mon FAI(free), mais via la même clef wifi, mon portable se connecte parfaitement à ces sites et ceci depuis linux et windows. Un point de plus qui me porte à croire que cela vient de ma configuration, sur la même machine depuis windows, aucun soucis avec pidgin, ou autre site...

Merci d'avance pour vos réponse.

[benjarobin]

Pidgin il faut sélectionner ton compte puis dans avancée tu coche la case Utiliser le protocole HTTP.
Et si tu pense que cela vienne du DNS pour ent.unistra.fr fait une résolution dns a la main avec la console, puis test avec l'IP ( 130.79.225.8 ) malheureusement les lien sont absolues (tu ne peux que tester l'accès à la page d'accueil, ou a chaque fois remplacer le nom par l'IP). Puis compare avec le nom de domaine...

[Soulou]

Bah en fait, je ne pense pas que ça vienne des DNS, puisqu'en utilisant les mêmes sou win, je n'ai aucun soucis...

Les ping sont tout à fait correct 35ms etc.... Je comprends vraiment pas. Quant à faire passer sur le port 80 pidgin, ça ne m'intéresse pas, surcharger un port n'a rien de bon, suffit que le port qu'il utilise soit ouvert et bien routé, ce qui est le cas, je vais tout de même tester.

[benjarobin]

Alors celle-ci on me l'avais jamais sortie, surcharger un port ^^, tu sais ce n'est que de simple requête HTTP. Comme en fait ton navigateur web. De plus si tu es derriere un routeur, tu n'as pas le choix, a moins de router correctement d'avoir une IP fixe (chose que je ne suis jamais arrivé a faire avec pidgin) je n'ai aucun problème avec ssh, serveur web et j'en passe... Et amsn utilise le protocole HTTP

[Skunnyk]

Les client messenger utilisent de base le protocole MSNP. Ils ne basculent en mode http que si ils n'arrivent pas à se connecter en MSNP (par exemple si le port est fermé). Heureusement qu'il n'y a pas besoin de configurer son routeur pour utiliser pidgin ou autre, sinon ça serait le bazard. (et MSNP n'est pas des "requêtes HTTP").
Sinon pour ton problème, en général les DNS de Free fonctionnent bien .. Pour écarter tout problème DNS, test avec opendns (http://www.opendns.com/) voir si cela fonctionne mieux.

Tu as d'autres problèmes réseaux ?

Sinon tente avec un wireshark afin de faire une analyse de trame pour voir ce qu'il se passe ... (je sais que ce n'est pas trivial mais aux grands mots les grands moyens )

[benjarobin]

Bon je ne comprend pas trop, cela marche très bien sur ce routeur, mais sur celui qui était chez moi, impossible de se connecter a msn, pourtant les ports de sortis ne sont pas bloqués, et msn sous windows utilisait bien http. Donc en faite cela venait de mon routeur, car celui que j'utilise autorise bien la connexion.
Donc pas de routage a faire, mais bien une ouverture du port de sortie (qui sont tous ouverts par défaut).

MSNP n'est pas des "requêtes HTTP")

je n'ai jamais dis le contraire, mais quand on coche la case http, c'est bien des requête http ? non ? la flemme de faire du wireshark

[Soulou]

J'avais déjà testé opendns, j'ai juste oublié de le dire, le problème reste le même, c'est bizarre.
Quant à la surcharge de port c'est pas une question de performance mais d'ordre, (en référence d'ailleurs à un article dans linux france magasine qui parle de ça.
je vais tenter wireshark, je post le résultat =)

[tuxce]

t'as essayé un autre navigateur ?
pour ce qui est de l'essai de pidgin sur un autre système linux, c'est la même version ?

[Soulou]

J'ai testé une ubuntu récemment et j'avais le même problème, pourtant c'est avec la 2.5 de pidgin et non la 2.6.
Quant aux navigateur, j'ai testé epiphany, firefox et chromium, même résultat sur les trois.

Je suis en train de m'amuser avec wireshark, mais c'est trop irrégulier...
Des fois aucun soucis, puis au bout de deux/trois pages, ça veut plus..

[Skunnyk]

Tu serais par exemple chez Alice, on pourrait essayer de voir du côté du MTU au niveau de l'interface réseau, mais chez Free je n'en ai jamais entendu parler !

[Soulou]

Je voulais uploader des screenshot, mais rien a faire ça ne veut pas non plus.

Donc le résultat de mon étude avec wireshark, ce sont ces messages :

TCP :

Code : Tout sélectionner

No.     Time        Source                Destination           Protocol Info
   1051 530.993419  192.168.0.1           81.52.160.203         TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 1051 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6), Dst: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
    Destination: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        Address: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        Address: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 81.52.160.203 (81.52.160.203)
Transmission Control Protocol, Src Port: 43294 (43294), Dst Port: http (80), Seq: 1, Ack: 1, Len: 1448

HTTP :

Code : Tout sélectionner

No.     Time        Source                Destination           Protocol Info
   1053 531.996711  192.168.0.1           69.63.187.19          HTTP     [TCP Retransmission] GET "$URL" HTTP/1.1 

Frame 1053 (1391 bytes on wire, 1391 bytes captured)
Ethernet II, Src: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6), Dst: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
    Destination: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        Address: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        Address: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 69.63.187.19 (69.63.187.19)
Transmission Control Protocol, Src Port: 54944 (54944), Dst Port: http (80), Seq: 2844, Ack: 47381, Len: 1325
Hypertext Transfer Protocol

FTP :

Code : Tout sélectionner

No.     Time        Source                Destination           Protocol Info
  17232 1998.333239 192.168.0.1           212.27.63.3           FTP-DATA [TCP Retransmission] FTP Data: 1460 bytes

Frame 17232 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6), Dst: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
    Destination: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        Address: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        Address: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 212.27.63.3 (212.27.63.3)
Transmission Control Protocol, Src Port: 59274 (59274), Dst Port: 59622 (59622), Seq: 1, Ack: 2, Len: 1460
FTP Data

Code : Tout sélectionner

No.     Time        Source                Destination           Protocol Info
   2660 1174.867571 212.27.60.27          192.168.0.1           FTP-DATA [TCP Previous segment lost] FTP Data: 1448 bytes

Frame 2660 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: FreeboxS_32:f4:db (00:07:cb:32:f4:db), Dst: Cisco-Li_ff:28:c6 (00:1e:e5:ff :28:c6)
    Destination: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        Address: Cisco-Li_ff:28:c6 (00:1e:e5:ff:28:c6)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        Address: FreeboxS_32:f4:db (00:07:cb:32:f4:db)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 212.27.60.27 (212.27.60.27), Dst: 192.168.0.1 (192.168.0.1)
Transmission Control Protocol, Src Port: 12216 (12216), Dst Port: 49728 (49728), Seq: 246161, Ack: 1, Len: 1448
FTP Data

Et donc ces messages TCP retransmission sont ceux qui se répète quand le net n'avant pas. quelque soit le type de connexion.

Edit 1 : Je précise pour ne pas vous embrouiller que 192.168.0.1 est l'ip de la machine, et 192.168.0.254 celui de la freebox.
Edit 2 : Tous ces messgaes sont noté dans wireshark comme "Bad TCP"

[Soulou]

Je me permets un double post pour cette victoire contre la machine

Grâce à mon meilleur pote : , j'ai pu voir que mon problème était lié au MTU, c'est à dire la taille maximale d'un paquet suivant un protocol TCP/IP.
Du coup grâce à ifconfig j'ai pu analyser le MTU attribué à ma clef Wifi qui était de 1500.

Après un petit tour sur wikipedia, je vois, MTU maximal en wifi : 1496, alors un petit

Code : Tout sélectionner

# ifconfig wlan0 mtu 1496

Et le problème est résolu.