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

F

Felix63

Membre actif
5 Avril 2007
262
2
Du pays de Vercingétorix
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 :-)
 
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
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 :-)
Cliquez pour agrandir...
 
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 :rolleyes:
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 :D

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 ?
 
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)
 
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
 
Polo35230 a dit:
Comme Remy, je n'ai pas la solution.
Le pb de Félix a été également traité sur un autre fil:
Cliquez pour agrandir...
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 :)
 
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...:confused:
 
Dernière édition:
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
 
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...:siffle:
 
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...
Cliquez pour agrandir...
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 ;-)
 
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...:confused:
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 ;-)
Cliquez pour agrandir...
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.
 
Dernière édition:
Polo35230 a dit:
Mais peut-être que quelqu'un sur le forum aura une idée de génie?;)
Cliquez pour agrandir...
Suis pas sûr que le sujet passionne :D

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.
Cliquez pour agrandir...
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
 
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
 
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...
 
Merci Remy pour ton dump (on voit tout de suite qu'on est pas sur les mêmes débits) :siffle:
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.
Cliquez pour agrandir...
Alors, là, je vais avoir besoin d'aide :D

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é'
 
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
 
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 ?
Cliquez pour agrandir...
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 !
Cliquez pour agrandir...
Tain, t'as la poisse...;)
 
alors c'est peut-être ton identifiant chez OVH qui a un problème.

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

Sujets similaires

stefhan
OVH (f*ck) OWA : accès aux anciens mails
Réponses
1
Affichages
2K
Web et e-mail
pouppinou
pouppinou
F
Firewall au niveau du FAI
Réponses
7
Affichages
2K
FAI et réseau Mac
Felix63
F
Calor45
Client VPN qui déconnecte quand accès web
Réponses
4
Affichages
6K
FAI et réseau Mac
plarry
P
G
Lion server : problème de réponse aux mails
Réponses
0
Affichages
2K
FAI et réseau Mac
guigui37
G
D
plus d'accès à mes comptes gmail
Réponses
6
Affichages
3K
FAI et réseau Mac
doris
D
Haut Bas