problème d'accès à ssl0.ovh.net en webmail

[Polo35230]

alors c'est peut-être ton identifiant chez OVH qui a un problème.

Ils ne peuvent pas réinitialiser ton mot de passe?

Ca pourrait être LA solution.
Il faut quand même espérer qu'OVH a bien vérifié que c'était pas ça...

Curieux quand même, je ne suis pas chez OVH, et quand je mets un identifiant et un mot de passe bidon, j'ai un beau message 'Erreur d'authentification". Normal!
Felixn'a pas ça, il n'a aucune réponse du serveur, mais au vu de sa trace, c'est logique.
Il envoie des datas qui ne sont pas acquittées par la couche tcp de la machine OVH.

Je pense qu le pb est chez OVH.
C'est un gros truc, ils doivent avoir une palanquée de serveurs et de machines virtuelles.

Je suis a peu près sûr que tu ne va pas sur la même machine queFelix (même si c'est la même adresse IP).
Ce qui me fait dire ça, c'est que quand tu te connectes, à l'ouverture de la session tcp d'authentification, OVH demande un MSS de 536 octets (comme moi), alors que pour Felix, il est de 1412
C'est pour ça que si Félix pouvait faire un essai avec un MSS plus petit (en tout cas inférieur ou égal à 536), ils serait deans les mêmes conditions réseau que toi.
Mais le pb est peut-être plus haut dans les couches...

 

[Felix63]

@Remy
ça peut pas être un pb d'identifiant. J'ai une vingtaine de comptes répartis sur 3 domaines (90plan) différents et c'est tout pareil...

@Polo35230
Quand tu dis que j'ai la poisse, tu mesures même pas l'ampleur
En plus de celui-là (qui est mineur en fait), j'ai :
- un pb d'iPhone depuis que je suis passé de Bouygues à Free, toutes mes applis téléchargées sur iTunes se ferment immédiatement après le lancement
- avec le MBP, en déplacement, je ne peux rejoindre aucun des hotspot wifi, il me met 'délai de connexion dépassé'
- je suis passé en FreeBox only et j'avais pas pensé que toutes mes prises téléphoniques dans différentes pièces de la maison seraient HS... Je cherche donc un plan de cablage pour réinjecter le signal issu de la Box et tout ce que je récupère m'oblige à modifier les prises males scellées...

Bon, j'avais décidé de faire toutes mes migrations en même temps pour regrouper les pb dans le temps... Je suis servi

Sinon pour ce qui nous concerne, j'ai un message d'Ovh me disant que c'est reparti en traitement. On va attendre donc pour faire le test du MTU (j'ai trouvé où c'était

Merci à vous deux et vive les forums

 

[Polo35230]

C'est pour ça que si Félix pouvait faire un essai avec un MSS plus petit (en tout cas inférieur ou égal à 536), ils serait deans les mêmes conditions réseau que toi.
Mais le pb est peut-être plus haut dans les couches...

J'y crois (un tt petit) peu.
Donc mettre une MTU à 450 pour tester...

La taille de la MTU est hyper importante quand sur le chemin, il y a des encapsulations supplémentaires dues par exemple à des tunnels (vpn, gre, ou autres), et que des équipements (routeurs par exemple) refusent la fragmentation. C'est rédhibitoire, tous les segments TCP qui dépassent la taille de la MSS négociée ne parviennent alors que partiellement à la machine distante. Donc celle-ci attend la suite qui ne lui parvient jamais...

Baisser la taille de la MTU est sans risque, on peut le faire n'importe quand. Pas besoin de rebooter la machine...

Tain, je vieillis, j'avais pas vu que tu avais répondu a 8h30

 

[r e m y]

...

- avec le MBP, en déplacement, je ne peux rejoindre aucun des hotspot wifi, il me met 'délai de connexion dépassé'

.....

"Délai de connexion dépassé" !!!

Il y a un problème sur ton MBP! C'est pas possible que tu aies le même problème pour te connecter chez OVH que pour te connecter sur un hotspot wifi!
Tu as dû modifier un paramètre quelque part qui empêche ton Mac de communiquer avec les serveurs auxquels tu cherches à le connecter

 

[Felix63]

Il y a un problème sur ton MBP! C'est pas possible que tu aies le même problème pour te connecter chez OVH que pour te connecter sur un hotspot wifi!

Je pense que ce sont des problèmes différents. Le fait qu'ils arrivent en même temps est du à la loi des emmerdements maximum
J'ai lu que l'histoire des hospots pouvait venir d'une sortie de veille en WiFi (un pb semble-t-il réccurent sous Lion). Celà pourrait être le cas, car ts les essais que j'ai fait étaient en sortie de veille.
Il faut juste que je teste en rallumant le MBP. Mais dans mon coin les hotspots sont rares et donc faut planifier...

Tu as dû modifier un paramètre quelque part qui empêche ton Mac de communiquer avec les serveurs auxquels tu cherches à le connecter

D'abord, je ne modifie jamais rien sur le MBP...
Ensuite, j'arrive quand même à aller sur des sites sécurisés... heureusement
Et puis, là, je suis en ethernet, wifi coupé.

 

[Felix63]

Donc mettre une MTU à 450 pour tester...

Bon, ça sera vite testé, car la plage autorisée sous Lion est comprise entre 1280 et 9000...:siffle:
Sinon, j'ai une réponse d'Ovh : ils ont tout testé (même ton analyse...). Ils me demandent de vérifier que le port 110 est bien ouvert sur la box ??
D'abord, je ne vois pas comment tester ça sur une FreeBox et puis, si je peux envoyer une commande TELNET sur ce port, c'est bien qu'il est ouvert, non ?

Pour info :
En déplacement ces derniers jours, j'ai pu tester sur un WiFi-Pass. C'est nickel
ça me rassure aussi sur l'histoire du 'délai de connexion dépassé' que j'avais sur les précédents FreeWifi, ça sera du au fait que le MBP sortait de veille.
En plus, j'ai découvert le monde de la vitesse (1Mbps, seulement, pourtant... qu'est-ce que ça doit être à 8Mbps
Et le problème se situe peut-être là : 512kbps, trop lent pour les serveurs mails d'Ovh
Qu'en pensez-vous ?

 

[Polo35230]

Curieux, comme demande...
Alors, il y a des sites sur le web pour tester lesconnexions entrantes qui servent à vérifier que la box laisse bien passer la demande d'ouverture de session, et que le port est bien ouvert sur le Mac; Par exemple:
http://www.ipfingerprints.com/portscan.php

Mais dans ton cas, OVH demande de vérifier si tu peux bien sortir sur le port 110.
Si tu arrives à faire un telnet sur un serveur pop, c'est que c'est bon.
Par exemple, chez moi, c'est bon:
iMac:~ Polo$ telnet pop.orange.fr 110
Trying 80.12.242.60...
Connected to pop.orange.fr.
Escape character is '^]'.

Pour moi, le débit n'est pour rien dans le pb.
Par contre, la MTU peut-être.
En déplacement, tu ne passe pas par le même chemin. De chez toi, tu passes peut-être par des tunnels, et certains équipements (qui ne fragmentent pas) peuvent bloquer les messages avec des MSS trop longs.
Peux-tu faire un essai avec 1280?
Pour la taille de la MTU, c'est curieux que ce soit bridé sous Lion.

 

[Tuncurry]

alors c'est peut-être ton identifiant chez OVH qui a un problème.

Via Free, connexion ce matin sur le webmail OVH et pour moi ca fonctionne impec.
En revanche toujours quelques petits soucis de reconnaissance de certificat dans Mail. Il faut revalider le certificat et se connecter manuellement pour que ca fonctionne. Je ne sais pas trop pourquoi...

 

[Polo35230]

Ce qui est curieux, c'est que ça a marché à partir d'un wifi-pass d'Orange.
Ca ne met pas hors de cause le certificat?

Je fais un blocage sur le chemin utilisé et la MTU, mais je fais peut-être fausse route ...

Par contre, je ne comprends pas pourquoi, OVH demande de tester le port 110, alors que c'est un webmail, et que tout doit être encapsulé dans du https (port 443).

 

[Felix63]

http://www.ipfingerprints.com/portscan.php

me donne 'filtered' sur le port 110
je ne sais pas l'interpréter

Le telnet est bon :
+OK Welcome to OVH Mail server 170

Peux-tu faire un essai avec 1280?
Pour la taille de la MTU, c'est curieux que ce soit bridé sous Lion.

Avec Lion, c'est dans réseau>avancé>matériel
et le test avec 1280 est idem à 1500

là, mon niveau de patience est largement dépassé. Ovh a atteint son objectif : pourrir la discussion. Tant pis, je lache
Merci pour ces petits instants passés ensemble

@ Tuncurry
Merci pour le test sur Free
Si, comme le dit Polo35230, la vitesse n'est en cause, reste que ce pb de certificat...

---------- Nouveau message ajouté à 11h33 ---------- Le message précédent a été envoyé à 11h29 ----------

J'avais pas lu ta réponse

Par contre, je ne comprends pas pourquoi, OVH demande de tester le port 110, alors que c'est un webmail, et que tout doit être encapsulé dans du https (port 443).

ça confirme qu'ils m'enfument
Encore merci !

 

[Polo35230]

me donne 'filtered' sur le port 110
je ne sais pas l'interpréter

C'est normal. le port 110 n'est pas (et n'a pas à être) ouvert sur ta machine.
De toute façon le test dans l'autre sens (telnet vers OVH) est bon sur le port 110. Donc le pb n'est pas là.

Reste que si tu as la solution (un jour...), j'aimerais bien la connaître.

 

[Felix63]

Reste que si tu as la solution (un jour...), j'aimerais bien la connaître.

A mon avis, c'est mort, mais, promis

 

[6nema]

Salut,
En voyant le nb de post, j'ai cru à une résolution dans le dernier post, mais hélas

Pour répondre à la question posée : mon FAI c'est ORANGE, fibre 20Mo.

le pb reste le même depuis des mois. Aucune connexion webmail OVH depuis nos locaux. (alors que ca fonctionnait auparavant).
Aucun probleme depuis iPhone (via SFR - même lieu) ou tout autre point d'accès externe à nos locaux. Mais l'iPhone refuse de se connecter au webmail en WIFI (donc sur notre réseau).

J'ai fais intervenir un technicien de notre FAI qui n'a pas su répondre à ce casse tête.
Ce technicien a pu se connecter au webmail avec son laptop (PC) une fois, puis plus du tout.

J'ajoute que les macbook qui ne se connectent pas en interne n'ont aucun pb dès qu'ils quittent les locaux...

OVH n'a, à ce jour, su apporter aucune réponse.

 

[Polo35230]

J'ajoute que les macbook qui ne se connectent pas en interne n'ont aucun pb dès qu'ils quittent les locaux...

Bonjour,

Donc, ce n'est pas un pb d'identifiant/mot de passe, ni de certificat.

Il reste l'hypothèse (sérieuse) du réseau
Soit sur le chemin (ils sont différents selon qu'on soit en interne, ou ailleurs)
Soit sur le lan d'ovh suivant le routage interne utilsé pour joindre leurs batteries de machines.

Je suis un maniaque de la trace, mais j'en reviens à la trace de Remy (qui est bonne), et la trace de Felix qui pose pb.
Je boucle sur la longueur des datagrammes IP dans le sens Mac vers OVH.
C'est un peu technique, mais, la MTU, la MSS, la fragmentation et les tunnels utilisés sur le chemin conditionnent l'acheminement correct des données.
On a vu plus haut dans le fil qu'il y avait une différence au niveau MSS entre la trace de Remy (536), et celle de Felix (1412).
On a vu aussi que certains datagrammes IP n'étaient pas acquittés par OVH. Peut-être à cause de leur longueur.

Un bon test à faire serait de baisser la taille de la MTU d'un des Mac, et de faire un essai en interne. La mettre à 300 (parce que 300 est inférieur à 536, et bien faire appliquer). J'y crois un peu.
Felix n'a pas pu faire l'essai (sur lion, la taille minimum est 1280).
Par contre, je suis sous snow leopard, et je peux mettre 300.

Autrement, si la manip ci dessus ne marche pas, il faudrait faire deux traces (avec le même mac). Une en interne (echec), et une de l'extérieur (réussite)

Se connecter (a partir d'un navigateur) sur roundcube (https://ssl0.ovh.net/roundcube/)
Une fois connecté, on a la demande d'authentification de RoundCube.
Dans une fenêtre Terminal, taper la commande suivante:
sudo tcpdump -c 50 -i en0 host 213.186.33.20 (c'est pour faire une trace de 50 lignes avec le serveur OVh. en0 si ethernet ou en1 si wifi)
Ensuite, dans Safari, renseigner l'utilisateur et le mot de passe.
Dans la fenêtre Terminal, ça doit défiler (34 lignes environ).
Après le message d'erreur de Rouncube, dans la fenêtre Terminal, faire CTL+C pour arrêter la trace.

En comparant les deux traces, on aura peut-être un début d'explication...

 

[6nema]

voilà les lignes du terminal après la manip plus haut (sous 10.8.2)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:40:39.257047 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags , seq 4264698767, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 599273248 ecr 0,sackOK,eol], length 0
15:40:39.259925 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [S.], seq 87147761, ack 4264698768, win 536, options [mss 1380], length 0
15:40:39.260142 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
15:40:39.261199 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 1:140, ack 1, win 65535, length 139
15:40:39.263260 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [.], ack 140, win 32629, length 0
15:40:39.264370 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [.], seq 1:1281, ack 140, win 32768, length 1280
15:40:39.264903 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [.], seq 1281:2561, ack 140, win 32768, length 1280
15:40:39.264938 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [.], ack 2561, win 65535, length 0
15:40:39.265147 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [P.], seq 2561:3233, ack 140, win 32768, length 672
15:40:39.265241 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [.], ack 3233, win 65535, length 0
15:40:39.273658 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 140:407, ack 3233, win 65535, length 267
15:40:39.273667 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 407:413, ack 3233, win 65535, length 6
15:40:39.273670 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 413:450, ack 3233, win 65535, length 37
15:40:39.283214 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [.], ack 413, win 32495, length 0
15:40:39.283527 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [P.], seq 3233:3276, ack 450, win 32768, length 43
15:40:39.283613 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [.], ack 3276, win 65535, length 0
15:40:39.283862 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1035, ack 3276, win 65535, length 585
15:40:39.283891 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 1035:1178, ack 3276, win 65535, length 143
15:40:39.286412 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [.], ack 450, win 32768, length 0
15:40:39.551799 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:39.853153 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:40.253753 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:40.754584 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:41.457630 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:42.665585 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:45.272893 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:47.885936 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:50.498821 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:53.114051 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:55.727182 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:40:58.337010 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [P.], seq 450:1178, ack 3276, win 65535, length 728
15:41:00.945137 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [R.], seq 1178, ack 3276, win 65535, length 0
15:41:00.947266 IP ns0.ovh.net.https > 192.168.0.103.54823: Flags [.], ack 450, win 32768, length 0
15:41:00.947311 IP 192.168.0.103.54823 > ns0.ovh.net.https: Flags [R], seq 4264699217, win 0, length 0

 

[Polo35230]

Alors, c'est exactement le mêm pb que celui de Felix, et au même endroit.
Les longueurs sont légèrement différentes, car les identifiants/mots de passe sont différents...
On voit que le mac envoie 450 octets qui sont bien acquittés par la machine OVH (ce sont des acquitemnts protocolaires, pas applicatifs), mais que le datagramme de longueur 585 n'est jamais acquitté par la machine OVH.
450+585=1035
La machine OVH acquitte les 450 octets, mais jamais les 1035.

Le datagrame de longueur 585 n'est: soit pas reçu, soit pas acquitté par la machine OVH.
Le Mac s'acharne, et envoie une douzaine de fois les 585+143=728 octets, mais sans succès. (même chose que Felix)
Un des Macs peut-être paramétré avec une MTU de 300?

L'intérêt de la manip, c'est que le datagramme de 585 serait alors segmenté en deux datagrammes (300+285). Je pense à la mss de 536 envoyé par OVH sur la trace de Remy (qui marchait).
Quelque chose me dit que quelquepart sur le chemin, des sondes QoS (genre ipanema) font mumuse avec la MSS...

On voit sur cette trace qu'OVH renvoie une MSS (1380) encore différente...

 

[6nema]

http://forums.ovh.net/showthread.php?t=85388


Et le blog officieux d'OVH :


http://ovh.wxop.com/posts.php?lang=fr

 

[Felix63]

http://forums.ovh.net/showthread.php?t=85388&page=9999

Yep, c'est marrant les coincidences
J'étais justement là-bas y a 2 minutes (je reste abonné à ces fils), mais incapable de poster dessus... dès que je poste une réponse, ça mouline 'En attente de forum.ovh...'
As-tu essayé de poster, toi aussi ?
Si on avait le même problème, on pourrait faire une pétition auprès d'Ovh

Je pense vraiment qu'ils ont des problèmes qu'il ne veulent pas reconnaître.
Le WE dernier, mon fils était à la maison avec son MBP et le traceroute n'a même pas pu balancer une trame. Le problème est qu'on a à faire à des incompétents qui filtrent les tickets !
Leur dernière réponse : pouvez-vous faire un essai avec un PC ou Linux ?
Je leur ai répondu que c'était pas demain la veille qu'un PC rentrerait à la maison

 

[Polo35230]

http://forums.ovh.net/showthread.php?t=85388


Et le blog officieux d'OVH :


http://ovh.wxop.com/posts.php?lang=fr

Oui, mais une connexion (à partir d'un même Mac) marche sur un site, et pas sur l'autre...
Je ne crois pas à un pb d'adresse IP. Vous vous seriez fait jeter à l'ouverture de session...
Je crois plutôt a un pb réseau (travaux, MTU, équilibrage de charge, au niveau paquet ou session) chez OVH.
Le test de MTU permettrait d'y voir un peu plus clair.

 

[6nema]

Salut

Les choses empirent, les accès au manager OVH V3 deviennent de plus en plus compliqués.
Je n'arrive quasiment plus à entrer sur l'interface... :mad:

Et quand, par miracle, je passe la page de connexion, les pages internes deviennent lentes, très lentes et finalement inaccessibles.
"Safari ne parvient pas à ouvrir la page car le serveur sur lequel cette pages est située ne réponds pas."

Et vous ?

---------- Nouveau message ajouté à 12h45 ---------- Le message précédent a été envoyé à 12h37 ----------

Est-ce que ça peut marcher ça ? :

http://forum.ovh.com/showthread.php?t=52903