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



## Felix63 (13 Janvier 2013)

Bonsoir à tous,
Je suis en quête de réponses sur un problème que je rencontre pour accéder à mes comptes mail avec l(es) webmail chez Ovh.
La situation :
Lorsque je tente d'accéder à ssl0.ovh.net avec firefox et un de leur webmail (Horde, Roundcube, ...), le serveur ne répond pas. En revanche, je peux poper mes comptes avec Thunderbird
La hotline d'Ovh me demande de faire un traceroute. Le résultat bloque au niveau de proxad (Free, mon FAI).
Ovh me répond que j'a un problème de Firewall chez Free...
Je tente un ping qui n'aboutit pas.
Je fais un test sur un ordi Mac aussi, mais chez Orange, le traceroute ne dépasse pas la livebox !
Qu'est-ce que ça veut dire ? un blacklistage d'Ovh ?

Si vous avez des pistes, ce sera avec grand plaisir


----------



## 6nema (18 Février 2013)

Salut Felix,

As-tu trouvé une piste depuis janvier ?
J'ai le même probleme depuis un site, impossible d'acceder au webmail OVH 
ni via l'URL, ni via l'IP du serveur  (213.186.33.20).
Le traceroute me sort une suite d'asterix (etoiles)...
Je peux uniquement passer en POP depuis MAIL ou OUTLOOK.
Ni OVH, ni mon FAI n'a su répondre à ce casse-tête...
C'est comme si on interrogeait un site mirroir virtuel.
Page d'acceuil OK mais des qu'on entre les identifiants ca mouline sans fin ou sort une erreur.
(Safari, Firefox ou Opera : même combat! )
:-(




Felix63 a dit:


> Bonsoir à tous,
> Je suis en quête de réponses sur un problème que je rencontre pour accéder à mes comptes mail avec l(es) webmail chez Ovh.
> La situation :
> Lorsque je tente d'accéder à ssl0.ovh.net avec firefox et un de leur webmail (Horde, Roundcube, ...), le serveur ne répond pas. En revanche, je peux poper mes comptes avec Thunderbird
> ...


----------



## Felix63 (19 Février 2013)

Salut,

Content que tu mettes fin à ma solitude ;-)
Pas de pistes sérieuses. Je suis toujours en relation avec la hotline Ovh (ticket n° 1252573) ; ça doit faire le 5ème conseiller depuis début janvier 
A chaque fois, on repart pour un tour. Là, ça fait 2 conseillers qui me demandent des tests du serveur, de changer de FAI (j'en ai 2, Orange et Free), puis "_Votre demande est prise en charge, elle est en cours de traitement_"... C'est clair qu'ils tentent de me décourager, mais j'ai décidé de m'accrocher 

J'ai vu sur leur forum une discussion à ce sujet (autour du 25 décembre), mais dès que je veux m'identifier pour participer, ça mouline !

Tu es chez quel FAI ?
Mac ou PC ?


----------



## r e m y (19 Février 2013)

Je ne sais pas comment contribuer, mais tout ce que je peux dire c'est que je suis chez Orange et je n'ai aucun souci pour accéder au webmail d'OVH (depuis mes Macs)


----------



## Polo35230 (19 Février 2013)

Bonjour,

Comme Remy, je n'ai pas la solution.
Le pb de Félix a été également traité sur un autre fil:
http://forums.macg.co/internet-et-reseau/firewall-au-niveau-du-fai-1214299.html

Si c'est tjs l'authentification chez OVH qui ne marche pas, un truc qui pourrait aider (et peut-être à transmettre à OVH), c'est de faire une trace pour prouver que le pb est bien chez eux.
Je ne suis pas chez OVH, mais de chez moi, je me connecte bien sur roundcube (via Safari), et avec le lien ci-dessous.
https://ssl0.ovh.net/roundcube/

Une fois connecté, j'ai bien la demande d'authentification de RoundCube.
Dans une fenêtre Terminal, je tape la commande:
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, je renseigne l'utilisateur, et le mot de passe (ils sont bidons, car je n'ai pas d'abonnement chez eux)
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.

Les lignes sont horodatées.
Sur la trace ci-dessous, on constate qu'après l'échec d'authentification, vers la fin, il y a une tempo OVH de 5 secondes, et on voit bien que c'est le serveur d'OVH qui coupe la session TCP  (c'est le flag F.)

Si c'est pareil chez vous, le pb est bien chez OVH, ou alors, le couple utilisateur-mot de passe n'est pas bon...

iMac:~ Polo$ sudo tcpdump -c 50 -i en0 host 213.186.33.20
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:38:20.933569 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags , seq 3202612453, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 337887516 ecr 0,sackOK,eol], length 0
11:38:20.956168 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [S.], seq 96501984, ack 3202612454, win 536, options [mss 536], length 0
11:38:20.956229 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
11:38:20.956722 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
11:38:20.979984 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [.], ack 160, win 32609, length 0
11:38:20.981879 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [.], seq 1:1281, ack 160, win 32768, length 1280
11:38:20.983050 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [.], seq 1281:2561, ack 160, win 32768, length 1280
11:38:20.983728 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [P.], seq 2561:3226, ack 160, win 32768, length 665
11:38:20.983778 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 3226, win 65535, length 0
11:38:20.988692 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [P.], seq 160:427, ack 3226, win 65535, length 267
11:38:20.988710 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [P.], seq 427:433, ack 3226, win 65535, length 6
11:38:20.988724 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [P.], seq 433:470, ack 3226, win 65535, length 37
11:38:21.020616 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [.], ack 433, win 32495, length 0
11:38:21.020768 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [P.], seq 3226:3269, ack 470, win 32768, length 43
11:38:21.020800 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 3269, win 65535, length 0
11:38:21.021026 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [P.], seq 470:993, ack 3269, win 65535, length 523
11:38:21.159695 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [.], seq 3269:4549, ack 993, win 32768, length 1280
11:38:21.160070 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [P.], seq 4549:4617, ack 993, win 32768, length 68
11:38:21.160119 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 4617, win 65535, length 0
11:38:21.160445 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [P.], seq 4617:5200, ack 993, win 32768, length 583
11:38:21.160482 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 5200, win 65535, length 0
11:38:21.168629 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [P.], seq 5200:5226, ack 993, win 32768, length 26
11:38:21.168686 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 5226, win 65535, length 0
11:38:26.215806 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [P.], seq 5226:5249, ack 993, win 32768, length 23
11:38:26.215808 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [F.], seq 5249, ack 993, win 32768, length 0  (c'est ici que le serveur OVH coupe la connexion)
11:38:26.215897 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 5249, win 65535, length 0
11:38:26.215927 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags [.], ack 5250, win 65535, length 0
^C
27 packets captured
30 packets received by filter
0 packets dropped by kernel


----------



## Felix63 (19 Février 2013)

Polo35230 a dit:


> Comme Remy, je n'ai pas la solution.
> Le pb de Félix a été également traité sur un autre fil:


Oui, c'était de moi et le résultat était retour vers Ovh...

On avait fait le test d'accès par Terminal et TELNET et c'était bon... seulement je me voyais pas relever mon courrier par TELNET 
On avait tout essayé : avec firewall(s) activés/désactivés, traceroute, ...
J'avais même découvert à l'occasion l'appli NETSAT du Mac quand même plus pratique que le Terminal (je ne suis vraiment pas à l'aise avec ces commandes).

Là, je viens de faire comme toi, avec CTRL/C après le message d'erreur (temps dépassé) de FireFox, mais je suis bien incapable d'interpréter le dump 
Voilà ce que ça donne :
MacBook:~ admin$ sudo tcpdump -c 50 -i en0 host 213.186.33.20
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:40:26.656138 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [P.], seq 1330362454:1330363009, ack 87047032, win 65535, length 555
17:40:29.341139 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [P.], seq 2949440273:2949440968, ack 96307335, win 65535, length 695
17:40:29.543156 IP 192.168.1.100.56452 > ns0.ovh.net.https: Flags [P.], seq 3995779141:3995779696, ack 96207031, win 65535, length 555
17:40:34.930295 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:40:37.544348 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [P.], seq 0:695, ack 1, win 65535, length 695
17:40:37.544441 IP 192.168.1.100.56452 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:40:37.544530 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [FP.], seq 317967644:317968199, ack 91134692, win 65535, length 555
17:40:43.204797 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:40:45.811274 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [P.], seq 0:695, ack 1, win 65535, length 695
17:40:45.811354 IP 192.168.1.100.56452 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:40:50.982296 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:40:53.595240 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [FP.], seq 0:555, ack 1, win 65535, length 555
17:40:53.696430 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [P.], seq 0:695, ack 1, win 65535, length 695
17:40:53.797618 IP 192.168.1.100.56452 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:40:59.258094 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:41:01.870990 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [P.], seq 0:695, ack 1, win 65535, length 695
17:41:01.871056 IP 192.168.1.100.56452 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:41:07.116007 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [P.], seq 0:555, ack 1, win 65535, length 555
17:41:09.732826 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [FP.], seq 0:555, ack 1, win 65535, length 555
17:41:09.833070 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [P.], seq 0:695, ack 1, win 65535, length 695
17:41:10.033665 IP 192.168.1.100.56452 > ns0.ovh.net.https: Flags [R.], seq 555, ack 1, win 65535, length 0
17:41:10.448087 IP ns0.ovh.net.https > 192.168.1.100.56452: Flags [.], ack 0, win 32768, length 0
17:41:15.061852 IP 192.168.1.100.56453 > ns0.ovh.net.https: Flags [R.], seq 555, ack 1, win 65535, length 0
17:41:15.228306 IP ns0.ovh.net.https > 192.168.1.100.56453: Flags [.], ack 0, win 32768, length 0
17:41:17.874522 IP 192.168.1.100.56454 > ns0.ovh.net.https: Flags [R.], seq 695, ack 1, win 65535, length 0
17:41:17.933908 IP ns0.ovh.net.https > 192.168.1.100.56454: Flags [.], ack 0, win 32768, length 0
17:41:25.807751 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [FP.], seq 0:555, ack 1, win 65535, length 555
17:41:42.174889 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [FP.], seq 0:555, ack 1, win 65535, length 555
17:41:58.530476 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [FP.], seq 0:555, ack 1, win 65535, length 555
17:42:14.876276 IP 192.168.1.100.56450 > ns0.ovh.net.https: Flags [R.], seq 556, ack 1, win 65535, length 0
^C
30 packets captured
1101 packets received by filter
0 packets dropped by kernel

J'aimerais bien connaître le FAI de *6nema*, puisqu'il a le même soucis.
Merci à *r e m y* pour le soutien, on sait au moins que ça marche pour certains


----------



## Polo35230 (19 Février 2013)

Bonjour Felix,

Alors, les traces sont différentes.
Il faut être sûr que les traces sont prises dans le même contexte, c'est à dire:
Se connecter sur:
https://ssl0.ovh.net/roundcube/
Dans une fenêtre Terminal, taper la commande tcpdump
Dans le navigateur, taper l'utilisateur et le mot de passe, puis sur le bouton "Authentification"
On doit alors voir la trace défiler dans le Terminal
Arrêter la trace après le message d'erreur.

Ma trace est cohérente. On ne voit que ce qui concerne l'authentification.
Après avoir cliqué sur" authentification", on voit que le navigateur de ma machine ouvre une session TCP avec la machine d'OVH.
La première ligne est la demande d'ouverture de session TCP (TCP Syn; c'est le flag ). le port TCP client est 50664 et le port du serveur OVH est le 443 (https)
11:38:20.933569 IP 192.168.1.10.50664 > ns0.ovh.net.https: Flags 
Ensuite, c'est le dialogue d'authentification (SSL TLSV1). On voit pas le détail, c'est une trace "a minima"
Vers la fin, le serveur OVH demande le déconnexion
11:38:26.215808 IP ns0.ovh.net.https > 192.168.1.10.50664: Flags [F.]  (c'est le [F.])
Le tout dure 6 secondes

Dans ta trace, on ne voit ni la demande d'ouverture de session, ni  la deconnexion.
Par contre, il y a une palanquée de sessions TCP ouvertes entre ta machine et le serveur d'OVH (sur les ports 56450, 56451, 56452, etc). Curieux....
J'ai l'impression que ta trace ne correspond pas à l'authentification.
Tu avais peut-être d'autres connexions en cours avec OVH?

Pas simple, le pb...


----------



## r e m y (19 Février 2013)

Je viens de rentrer chez moi et j'ai refait un essai. 
Ca fonctionne... par contre l'URL que j'utilise est

https://ssl0.ovh.net/test/roundcube/?page=login










J'ai essayé avec  https://ssl0.ovh.net/roundcube/?_task=login    ca fonctionne aussi, mais je n'arrive pas sur la même version de RoundCube


----------



## Felix63 (20 Février 2013)

Merci à vous deux pour le soutien 
L'URL donné par la hotline Ovh est bien : *https://ssl0.ovh.net/roundcube/*
J'ai une réponse de leur part ce matin. Ils ont mis à jour mon service mail et me demandent de recommencer le test.
Même résultat !
ça fait +sieurs fois que je leur dis que le problème est identique quelque soit le service/compte, mais bon, je crois qu'ils m'amusent !

Pour notre discussion, les conditions étaient effectivement différentes (c'était avant l'authentification)...
Je viens de recommencer avec Safari (cf. ci-dessous), mais ça se termine toujours sur un flag [R], jamais sur un [F]


MacBook:~ admin$ sudo tcpdump -c 50 -i en0 host 213.186.33.20
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:22:49.773487 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags , seq 556123735, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1131104539 ecr 0,sackOK,eol], length 0
08:22:49.836511 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [S.], seq 100571443, ack 556123736, win 536, options [mss 1412], length 0
08:22:49.836737 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
08:22:49.837541 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 1:144, ack 1, win 65535, length 143
08:22:49.912370 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [.], ack 144, win 32625, length 0
08:22:49.933475 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [.], seq 1:1281, ack 144, win 32768, length 1280
08:22:49.952338 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [.], seq 1281:2561, ack 144, win 32768, length 1280
08:22:49.952443 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [.], ack 2561, win 65535, length 0
08:22:49.962796 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [P.], seq 2561:3226, ack 144, win 32768, length 665
08:22:49.962936 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [.], ack 3226, win 65535, length 0
08:22:49.970649 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 144:411, ack 3226, win 65535, length 267
08:22:49.970699 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 411:417, ack 3226, win 65535, length 6
08:22:49.970712 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 417:454, ack 3226, win 65535, length 37
08:22:50.055325 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [.], ack 417, win 32495, length 0
08:22:50.057194 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [P.], seq 3226:3269, ack 454, win 32768, length 43
08:22:50.057383 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [.], ack 3269, win 65535, length 0
08:22:50.057694 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 454:1031, ack 3269, win 65535, length 577
08:22:50.057778 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 1031:1172, ack 3269, win 65535, length 141
08:22:50.168591 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [.], ack 454, win 32768, length 0
08:22:50.474631 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 454:1172, ack 3269, win 65535, length 718
_[] 11 lignes identiques à la précédente_
08:23:49.935197 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [R.], seq 3269, ack 454, win 32768, length 0
^C
32 packets captured
56 packets received by filter
0 packets dropped by kernel

Merci de votre patience


----------



## Polo35230 (20 Février 2013)

Bon, la trace est bonne.
En comparant les traces, on voit que tu ne te fais pas jeter (comme moi) sur un pb d'utilisateur-mot de passe.
Si on compare ta trace et la mienne, elles sont identiques jusqu'à la ligne 15 environ.
J'ai regadé ma trace de connexion avec wireshark, qui donne le détail protocolaire de l'échange.
Je regarderai plus en détail dans la journée, mais j'ai l'impression qu'on est en plein dialogue de confirmation de la validité du certificat...
C'est peut-être à ce niveau que ça coince...

Mais j'extrapole, car j'interprète ta traçe à partir de la mienne. Pas l'déal...


----------



## Felix63 (20 Février 2013)

Polo35230 a dit:


> mais j'ai l'impression qu'on est en plein dialogue de confirmation de la validité du certificat...
> C'est peut-être à ce niveau que ça coince...


J'en suis arrivé à cette conclusion aussi parce que la dernière fois que je me suis connecté par webmail chez Ovh (mais ça remonte à longtemps) ça fonctionnait sans certificat...
Depuis, ils ont mis en place ssl et on peut en conclure que c'est ça qui pose problème !
Maintenant, comment le régler coté utilisateur (webmail donc)....
Bon, après, c'est pas dramatique, il reste l'accès en IMAP, mais, pour moi, c'est un principe 

Là, côté Hotline, je leur ai envoyé le tcpdump (grâce à toi), on va bien voir.
reste que j'aurais bien aimé leur mettre le nez dans leur m...e ;-)


----------



## Polo35230 (20 Février 2013)

Bon, alors le mystère s'épaissit...

Le client (le Mac) se présente bien au serveur; 
Suivent des échanges propres à la génération des clés de chiffrement.
Ensuite, le serveur d'OVH envoie le segment TCP ci-dessous . 
08:22:50.057194 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [P.], seq 3226:3269, ack 454, win 32768, length 43
Cette ligne (c'est un change cipher spec) signifie entre autres qu'il y a 43 octets de datas, qu'elle acquitte 454 octets précédemment envoyés par le Mac depuis l'ouverture de la session.

C'est ensuite que ça foire.
Le Mac envoie alors les deux segments TCP ci-dessous (de longueurs 577 et 141)
08:22:50.057694 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 454:1031, ack 3269, win 65535, length 577
08:22:50.057778 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 1031:1172, ack 3269, win 65535, length 141

OVH devrait alors acquitter 454+577+141, soit 1172 octets, mais il ne le fait pas. Il acquitte toujours 454 octets.
Tout se passe comme si le serveur n'avait pas reçu les 577+141 octets envoyés par le Mac (ligne ci-dessous).
08:22:50.168591 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [.], ack 454, win 32768, length 0

Courageusement, le Mac envoie à nouveau les 577+141 octets ci-dessous, mais en une seule fois (577+141=718)
08:22:50.474631 IP 192.168.1.100.57185 > ns0.ovh.net.https: Flags [P.], seq 454:1172, ack 3269, win 65535, length 718
Ne recevant pas d'acquittement du serveur OVH (ack 1172), le Mac s'acharne et renvoie les 718 octets 11 fois, mais ceux-ci ne sont jamais acquittés.
On voit bien qu'à la dernière ligne, il en est tjs à acquitter les 454 premiers octets envoyés par le Mac:
08:23:49.935197 IP ns0.ovh.net.https > 192.168.1.100.57185: Flags [R.], seq 3269, ack 454, win 32768, length 0

Il faut positiver. On constate le pb, mais on ne peut pas le résoudre...
Comme dit plus haut, tout se passe comme si le serveur d'OVH n'avait pas reçu, ou ne traitait pas ces 718 octets. Mais pourquoi?
On peut aussi supposer que quelque part, ils soient bloquées par un équipement (firewall?), mais j'y crois pas trop.
Une trace sur le serveur d'OVH permettrait d'en savoir plus, mais ça m'étonnerait qu'ils le fassent...

Mais peut-être que quelqu'un sur le forum aura une idée de génie?




Felix63 a dit:


> Là, côté Hotline, je leur ai envoyé le tcpdump (grâce à toi), on va bien voir.
> reste que j'aurais bien aimé leur mettre le nez dans leur m...e ;-)


Tu as bien fait de leur envoyer la trace. Une trace wireshark aurait été mieux.
Envoie leur aussi mon analyse ci-dessus, ça pourra peut-être les aider.

En complément, si tu veux vraiment leur envoyer une trace protocolaire qu'ils pourront réinjecter dans un analyseur de réseau, il faut refaire la trace en rajoutant une option dans la commande tcpdump.
sudo tcpdump -w tracetcpdump.pcap -c 50 -i en0 host 213.186.33.20
La trace ne défilera pas dans la fenêtre Terminal, mais s'écrira dans le fichier tracetcpdump.pcap
Pour sortir, il faudra aussi faire CTL+C

Le fichier tracetcpdump.pcap se trouvera dans le finder directement sous la petite maison.


----------



## Felix63 (20 Février 2013)

Polo35230 a dit:


> Mais peut-être que quelqu'un sur le forum aura une idée de génie?


Suis pas sûr que le sujet passionne 



> Tu as bien fait de leur envoyer la trace. Une trace wireshark aurait été mieux.
> Envoie leur aussi mon analyse ci-dessus, ça pourra peut-être les aider.


Je viens de leur envoyer ton analyse et le tracetcpdump.pcap.
Là, je suis sur les équipes de nuit chez eux 

Affaire à suivre
Merci pour ton aide


----------



## r e m y (20 Février 2013)

Bon je ne sais pas si ça peut aider, mais je vous ai fait un dump depuis mon Mac qui se connecte sans souci au WebMail d'OVH (via ORANGE comme FAI)



tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:21:16.224527 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags , seq 1467109790, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 415601523 ecr 0,sackOK,eol], length 0
19:21:16.243350 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [S.], seq 85661887, ack 1467109791, win 536, options [mss 536], length 0
19:21:16.243433 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
19:21:16.243680 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
19:21:16.268526 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], ack 160, win 32609, length 0
19:21:16.270736 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], seq 1:1281, ack 160, win 32768, length 1280
19:21:16.271903 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], seq 1281:2561, ack 160, win 32768, length 1280
19:21:16.272649 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [P.], seq 2561:3226, ack 160, win 32768, length 665
19:21:16.272715 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 3226, win 65535, length 0
19:21:16.278076 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [P.], seq 160:427, ack 3226, win 65535, length 267
19:21:16.278119 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [P.], seq 427:433, ack 3226, win 65535, length 6
19:21:16.278141 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [P.], seq 433:470, ack 3226, win 65535, length 37
19:21:16.306519 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], ack 433, win 32495, length 0
19:21:16.306706 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [P.], seq 3226:3269, ack 470, win 32768, length 43
19:21:16.306758 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 3269, win 65535, length 0
19:21:16.306967 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [P.], seq 470:1002, ack 3269, win 65535, length 532
19:21:16.528595 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], ack 1002, win 32236, length 0
19:21:16.537115 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], seq 3269:4549, ack 1002, win 32768, length 1280
19:21:16.537343 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [P.], seq 4549:4616, ack 1002, win 32768, length 67
19:21:16.537388 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 4616, win 65535, length 0
19:21:16.537396 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [P.], seq 4616:5278, ack 1002, win 32768, length 662
19:21:16.537428 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 5278, win 65535, length 0
19:21:16.548887 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [P.], seq 5278:5304, ack 1002, win 32768, length 26
19:21:16.548971 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 5304, win 65535, length 0
19:21:16.913021 IP 10.0.1.200.59057 > ns0.ovh.net.https: Flags , seq 3943825555, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 415601530 ecr 0,sackOK,eol], length 0
19:21:16.913512 IP 10.0.1.200.59058 > ns0.ovh.net.https: Flags , seq 1910451660, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 415601530 ecr 0,sackOK,eol], length 0
19:21:16.913984 IP 10.0.1.200.59059 > ns0.ovh.net.https: Flags , seq 3923939233, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 415601530 ecr 0,sackOK,eol], length 0
19:21:16.914817 IP 10.0.1.200.59060 > ns0.ovh.net.https: Flags , seq 2156704948, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 415601530 ecr 0,sackOK,eol], length 0
19:21:16.915458 IP 10.0.1.200.59061 > ns0.ovh.net.https: Flags , seq 1021495392, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 415601530 ecr 0,sackOK,eol], length 0
19:21:16.932031 IP ns0.ovh.net.https > 10.0.1.200.59057: Flags [S.], seq 98951387, ack 3943825556, win 536, options [mss 536], length 0
19:21:16.932127 IP 10.0.1.200.59057 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
19:21:16.932374 IP 10.0.1.200.59057 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
19:21:16.933805 IP ns0.ovh.net.https > 10.0.1.200.59058: Flags [S.], seq 87585197, ack 1910451661, win 536, options [mss 536], length 0
19:21:16.933877 IP 10.0.1.200.59058 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
19:21:16.934098 IP 10.0.1.200.59058 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
19:21:16.938088 IP ns0.ovh.net.https > 10.0.1.200.59059: Flags [S.], seq 94719374, ack 3923939234, win 536, options [mss 536], length 0
19:21:16.938162 IP 10.0.1.200.59059 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
19:21:16.938385 IP 10.0.1.200.59059 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
19:21:16.939945 IP ns0.ovh.net.https > 10.0.1.200.59060: Flags [S.], seq 99752666, ack 2156704949, win 536, options [mss 536], length 0
19:21:16.939949 IP ns0.ovh.net.https > 10.0.1.200.59061: Flags [S.], seq 90358046, ack 1021495393, win 536, options [mss 536], length 0
19:21:16.940022 IP 10.0.1.200.59060 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
19:21:16.940082 IP 10.0.1.200.59061 > ns0.ovh.net.https: Flags [.], ack 1, win 65535, length 0
19:21:16.940242 IP 10.0.1.200.59060 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
19:21:16.940396 IP 10.0.1.200.59061 > ns0.ovh.net.https: Flags [P.], seq 1:160, ack 1, win 65535, length 159
19:21:16.954407 IP ns0.ovh.net.https > 10.0.1.200.59057: Flags [.], ack 160, win 32609, length 0
19:21:16.955693 IP ns0.ovh.net.https > 10.0.1.200.59057: Flags [.], seq 1:1281, ack 160, win 32768, length 1280
19:21:16.956608 IP ns0.ovh.net.https > 10.0.1.200.59057: Flags [.], seq 1281:2561, ack 160, win 32768, length 1280
19:21:16.956646 IP ns0.ovh.net.https > 10.0.1.200.59057: Flags [P.], seq 2561:3226, ack 160, win 32768, length 665
19:21:16.956648 IP ns0.ovh.net.https > 10.0.1.200.59058: Flags [.], ack 160, win 32609, length 0
19:21:16.956691 IP 10.0.1.200.59057 > ns0.ovh.net.https: Flags [.], ack 3226, win 65535, length 0
50 packets captured
430 packets received by filter
192 packets dropped by kernel


----------



## Polo35230 (20 Février 2013)

Merci Remy,

Maintenant, on a une trace qui qui foire à cause d'un couple utilisateur-mot de passe qui n'existe pas (la mienne)
Une trace qui correspond a une connexion réussie (la tienne)
Et une trace avec une bizarrerie au niveau des acquittements (celle de Felix)

Sur la trace de Remy, on voit bien, qu'après le segment TCP  (qu'après le segment TCP de 43 octets), les 532 octets envoyés par le Mac sont bien acquittés par le serveur OVH (c'est le ack 1002 (470+532)), alors que la trace de Felix montre que ce qui est envoyé par son Mac au même niveau ne l'est pas...
19:21:16.306706 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [P.], seq 3226:3269, ack 470, win 32768, length 43
19:21:16.306758 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [.], ack 3269, win 65535, length 0
19:21:16.306967 IP 10.0.1.200.59056 > ns0.ovh.net.https: Flags [P.], seq 470:1002, ack 3269, win 65535, length 532
19:21:16.528595 IP ns0.ovh.net.https > 10.0.1.200.59056: Flags [.], ack 1002, win 32236, length 0

Autrement, entre la trace de Remy, et celle de Felix, il y a une autre bizarrerie au niveau MSS dans l'ouverture de session TCP (au niveau du MSS)
La taille du MSS dépend de la taille de la MTU (en principe 1500-40, soit 1460)
Elle est négociée (au plus bas) à l'établissement de la connexion entre le Mac et le serveur OVH.

Remy propose une MSS de 1460 (il a une MTU de 1500). Le serveur lui dit: pas possible, on va échanger avec une MSS de 536. C'est donc avec des segments TCP de 536 octets que les machines vont échanger (c'est le cas sur ma trace également)
Par contre, sur la trace de Felix, son Mac propose 1460, mais le serveur impose 1412. Curieux...

Ca n'a peut-être rien à voir, mais un bon test à faire pour Felix serait de configurer le réseau avec une taille de MTU de 300, et de refaire un essai.
Si c'est pas bon, il faudra remettre 1500 (c'est mieux pour les performances)
Si c'est bon, il ne faudra pas rester non plus sur 300. On verra alors...


----------



## Felix63 (21 Février 2013)

Merci Remy pour ton dump (on voit tout de suite qu'on est pas sur les mêmes débits) 
C'était à partir du MBP ? et tu as quoi comme éléments de sécurité, si c'est pas indiscret ?



Polo35230 a dit:


> Ca n'a peut-être rien à voir, mais un bon test à faire pour Felix serait de configurer le réseau avec une taille de MTU de 300, et de refaire un essai.


Alors, là, je vais avoir besoin d'aide 

Que pensez-vous du résultat positif avec TELNET ?

Par ailleurs, je ne sais pas si ça peut aider, mais j'ai un peu le même problème avec le forum Ovh : dès que je m'identifie pour poster, je me retrouve dans la situation de 'temps dépassé'


----------



## r e m y (21 Février 2013)

et tu as essayé de te créer une nouvelle session utilisateur sur ton Mac pour voir si tu es toujours confronté aux mêmes problèmes?
(voire depuis un autre Mac?)

Il y a peut-être quelque chose sur ton Mac ou ta session qui bloque le processus d'authentification... surtout si tu as le même problème sur les forums d'OVH


----------



## Felix63 (21 Février 2013)

Oui, j'ai essayé sur un autre Mac qui est chez un autre FAI (Orange), c'est pareil !


----------



## Polo35230 (21 Février 2013)

Salut Félix,

Pour changer la MTU, sous Snow Léopard, c'esrt dans:
Pomme---Préférences Système---Réseau--Avancé---Ethernet
Ensuite, "Configurer: Manuellement", et on change la valeur de la MTU. 
Mets 400 (au lieu de 1500)

Sur Lion, je ne sais pas où c'est dans la configuration réseau, mais je crois avoir vu un post sur le forum qu'il y a un onglet "Matériel". C'est là dedans. Enfin, je crois...



Felix63 a dit:


> Que pensez-vous du résultat positif avec TELNET ?


Un "telnet @IP n°DePort" sert seulement à savoir si on peut joindre l'appli (associée au n° de port) de la machine distante.
On ne remonte pas plus loin dans la couche applicative...



Felix63 a dit:


> Oui, j'ai essayé sur un autre Mac qui est chez un autre FAI (Orange), c'est pareil !


Tain, t'as la poisse...


----------



## r e m y (21 Février 2013)

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

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


----------



## Polo35230 (21 Février 2013)

r e m y a dit:


> 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 (22 Février 2013)

@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 (22 Février 2013)

Polo35230 a dit:


> 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 (22 Février 2013)

Felix63 a dit:


> ...
> 
> - 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 (22 Février 2013)

r e m y a dit:


> 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 (28 Février 2013)

Polo35230 a dit:


> 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...
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 (28 Février 2013)

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 (28 Février 2013)

r e m y a dit:


> 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 (28 Février 2013)

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 (28 Février 2013)

Polo35230 a dit:


> 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 


Polo35230 a dit:


> 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 (28 Février 2013)

Felix63 a dit:


> 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 (28 Février 2013)

Polo35230 a dit:


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


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


----------



## 6nema (6 Mars 2013)

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 (6 Mars 2013)

6nema a dit:


> 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 (6 Mars 2013)

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 (6 Mars 2013)

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 (6 Mars 2013)

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


Et le blog officieux d'OVH :


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


----------



## Felix63 (6 Mars 2013)

6nema a dit:


> 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 (6 Mars 2013)

6nema a dit:


> http://forums.ovh.net/showthread.php?t=85388
> 
> 
> Et le blog officieux d'OVH :
> ...



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 (27 Mars 2013)

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... 

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


----------



## Felix63 (27 Mars 2013)

6nema a dit:


> Est-ce que ça peut marcher ça ? :
> 
> http://forum.ovh.com/showthread.php?t=52903


Je vois pas le rapport 
T'entends quoi comme réponse par cette question ?

Sinon, pour la lenteur du manager, t'as essayé ce lien https://www.ovh.com/manager/web/ ?
C'est leur nouvelle interface v6. D'après Octave, il paraît que ça décoiffe...
Je ne peux pas dire, je ne dépasse pas l'identification 

A part ça, je t'avais posé une question le 06/03/2013 à 18h10, je ne crois pas avoir eu de réponse


----------



## Polo35230 (27 Mars 2013)

J'avais pas vu non plus...

Perso, j'en reviens aux traces analysées plus haut, et les paquets envoyés par le Mac non acquittés (par OVH?) au dessus de 500 octets (environ), et à l'hypothèse de la taille de la MTU.
On a vu que sous lion, on ne peut pas mettre une MTU inférieure à 1280 dans les préférences réseau.
Mais dans le Terminal, on doit pouvoir...

Pour modifier la MTU en ethernet.
Faire un  ifconfig, et regarder la valeur de la MTU dans en0.  En principe, il doit y avoir 1500
Faire:
sudo ifconfig en0 mtu 400
puis un ifconfig pour vérifier que la MTU à 400 octets est bien prise en compte.

Voir si ça change quelque chose avec OVH pour l'authentification.
Remettre ensuite la MTU à 1500 (400, c'est pas bon pour les performances (overhead protocolaire élevé...))

La manip est sans risque...


----------



## 6nema (27 Mars 2013)

Felix63 a dit:


> Je vois pas le rapport
> T'entends quoi comme réponse par cette question ?



je me demandais si on ne pouvais pas reconfigurer l'interface via le manager pour attaquer OVH non pas par leur IP principale mais par le cluster002.

Historiquement, j'avais eu un premier probleme d'acces FTP, et un technicien d'OVH m'avais à l'époque orienté sur le cluster002 pour entrer en FTP.


(et pour répondre à l'autre question, non je n'ai jamais tenté de poster sur le forum OVH en question...)


----------



## Felix63 (28 Mars 2013)

6nema a dit:


> (et pour répondre à l'autre question, non je n'ai jamais tenté de poster sur le forum OVH en question...)


Dommage !

---------- Nouveau message ajouté à 11h53 ---------- Le message précédent a été envoyé à 11h37 ----------




Polo35230 a dit:


> La manip est sans risque...


Pour ma part, c'est juste que vu le peu d'intérêt qu'ils portent à mon problème, je ne vois pas pourquoi je passerais plus de temps la-dessus.
C'est le vrai bordel chez ovh tout de suite (cf. le pb du manager). Donc je transfers peu à peu l'ensemble de mes comptes ailleurs.


----------



## 6nema (28 Mars 2013)

Un début de solution, sorte de plan B au probleme webmail OVH

passer par l'URL suivante :

http://webmailnew.ovh.com/

(pour moi ca fonctionne)
mais toujours pas de solution concernant l'acces au manager...


----------



## Felix63 (28 Mars 2013)

ça me suffit largement 
curieux que FireFox ne propose pas de retenir le mot de passe
on peut savoir comment tu as eu ce plan B ?


----------



## 6nema (28 Mars 2013)

ça vient d'un technicien OVH que j'ai eu au tél ce matin.


----------



## Felix63 (28 Mars 2013)

OK, merci
Mais chut... ils m'avaient dit qu'ils n'avaient pas d'accès non sécurisé ;-)


----------



## Polo35230 (28 Mars 2013)

6nema a dit:


> ça vient d'un technicien OVH que j'ai eu au tél ce matin.



Ça confirme que depuis le début, le pb n'était pas du côté client, mais qu'ils ont un pb non localisé chez eux sur certains de leurs équipements.
Ils ont trouvé une solution de contournement...
Je suis lourd, mais je suis quasiment certain que ça tourne autour du MSS...
C'est quand même étonnant de voir que certains de leurs équipement renvoient une valeur de MSS de 536 octets qui correspond à une valeur par défaut, ou à des équipements (du genre routeurs) qui sont en général utilisés pour accueillir des flux de backup en numéris.
Possible aussi que certains routeurs chez eux soient mal configurés pour s'adapter aux variations de MSS (commande "ip tcp adjust-mss" sur les équipements cisco ou cisco like)

Mais l'important, c'est que ça marche...


----------



## Felix63 (29 Mars 2013)

Polo35230 a dit:


> Mais l'important, c'est que ça marche...


Oui 
Surtout, on touche plus à rien... même pas mettre [résolu] sur le fils, hein


----------



## whatmail (2 Avril 2013)

Bonjour,

j'ai exactement le même problème, impossible d'accéder à https://ssl0.ovh.net/roundcube.

Après 2 heures d'efforts, j'ai tout essayé (mais alors vraiment tout au risque d'avoir tout mon système a réinstaller), et finalement j'ai trouvé une solution :

1. Aller dans trousseau d'accès (dans les applications/utilitaires)
2. dans catégorie, sélectionner tous les éléments
3. dans la zone de recherche, taper ssl0.
4. sélectionnez tous les certificats ssl0.ovh.net
5. les supprimer (taper n x le mot de passe admin pour n x certificats)
quitter votre navigateur et le relancer.
Ca fonctionne maintenant (enfin ici).

C'est du à leur problème de certificat non valide d'il y a quelques mois. J'avais accepté de les valider (boite à cocher 'afficher le certificat' sur message d'erreur 'certificat invalide').
Ensuite lorsque le certificat est redevenu ok, Mac OS X se mélange les pinceaux...

Hope this helps !


----------



## Felix63 (2 Avril 2013)

Content que ça ait pu marcher pour toi 
Dans mon cas, comme je n'ai aucun certificat ssl0 d'ovh, ça le fait pas...
Ceci dit la solution de _6nema_ me convient très bien tant qu'elle fonctionne


----------



## whatmail (7 Avril 2013)

ce qui m'a mis la puce à l'oreille c'est que le comportement etait le même sur tous les navigateurs de mon Mac alors que sur Windows il n'y avait aucun problème à passer par l'adresse par défaut de roundcube.

Je te signale quand même que la connexion par http://webmailnew.ovh.com/ n'est pas chiffrée contrairement à celle de https://ssl0.ovh.net/roundcube/.

Tu peux aussi essayer de supprimer le certificat racine AlphaSSL CA - G2 depuis le Trousseau d'accès, il est peut être mal configuré.

Il se recréera tout seul.


----------



## 6nema (2 Mai 2013)

whatmail a dit:


> Bonjour,
> finalement j'ai trouvé une solution :
> 
> 1. Aller dans trousseau d'accès (dans les applications/utilitaires)
> ...



aucun certificat ssl chez moi non plus.
donc ca ne marche pas.


----------

