Timeout sur connection TCP IP

Bonsoir,
j'ai regardé dans le forum mais je n'ai rien trouvé sur ce sujet.
Mon problème est le suivant, j'ai développé une application en Visual C# qui interroge une BDD MySql sur un serveur Linux Ubuntu. Je n'ai aucun problème de connexion ni d'utilisation des données lorsque je me connecte via mon réseau privé. Lorsque je passe par Internet, je peux voir sur le serveur que ma connexion est ouverte, authentification réussie mais aucune donnée n'est renvoyée par le serveur et j'obtiens donc un timeout au bout de 30 s.
Auriez vous une piste à me suggérer car là je dois bien avouer que je suis sec...

Merci d'avance

PS: ai-je posté au bon endroit ?

Citation:

---

diagnostique différenciel

réso => ça marche
démon mysql => etat inconnu
connexion mysql => état inconnu
requete envoyée par client => état inconnu
requete conforme => état inconnu
resultat existant => état inconnu
résultats lus par le client => état inconnu.

---

comment tu veux qu'on t'aide?

---
note
à la relecture, la couche réseau demande une meilleure caractérisation pisque tu traverses petre pas tes équipement de niveau 3. Mais si je devais parier, je dirais que le serveur refuse la connexion depuis internet (ou n'écoute pas du tout autre chose que localhost, deux problèmes différents, 90% des problemes que mes collegues n'avaient pas pour configurer leur base mysql parce que je finissais par le faire.)

Bonsoir et merci pour la réponse,
en fait
le réseau fonctionne bien, le daemon mysql tourne, mysql écoute 0.0.0.0 c'est à dire tout (je sais ce n'est pas prudent mais j'arrangerai cela plus tard), les requêtes envoyées sont valides puisque envoyées à travers le réseau local elles fournissent des réponses cohérentes.
Lorsque je regarde qui est connecté à la base avant ma connexion à travers internet depuis mon soft, je ne vois que le root: normal.
Ensuite je lance mon soft et là je me vois en tant qu'utilisateur non authentifié pendant quelques petites secondes et enfin authentifié. Tout semble donc se passer correctement sauf que je ne récupère aucune réponse de la BDD.
Cela peut-il venir du routeur mal configuré ?

au niveau mysql l'utilisateur a donc acces depuis n'importe quelle machine?

est ce que tu peux te connecter à ta base depuis internet avec un autre client?

Citation:

---

Envoyé par ebgérard

Cela peut-il venir du routeur mal configuré ?

---

tant que tu fais du niveau 3, probablement pas. si tu fais de la traduction d'adresse, c'est plus la même histoire. Je suppose que tu pingues ton serveur? Est ce que telnet sur le port d'écoute de ton serveur mysql passe?

Bonjour et merci
après une petite recherche de telnet (windows 7...) j'ai lancé une connexion telnet vers le serveur qui donne:
@5.1.41-3ubuntu12.6<;=^DxQiDs9'Ws^[0y5;
ce qui pour moi est du charabia puis environ 5 à 10 s plus tard renvoie
perte de connexion à l'hôte.

L'information intéressante c'est que le serveur a répondu sur le port mysql depuis internet à l'établissement d'une connexion même si c'est un client telnet qui se connecte.
C'est pas comme si on allait parler courament le protocole d'échange des données entre un serveur mysql et son client. déjà qu'en http c'est chiant... le time-out sur ce telnet est explicable.

Zut ça fait un coupable en moins.

J'aurai bien une solution de contournement du probleme mais pas une solution tout court. La solution ça serait d'activer du démon openssh et de faire passer les requetes via un tunnel ssh.

il faut que je m'informe plus sur mysql pour t'aider.

juste par acquis de conscience je voudrais un
netstat --inet -l et le résultat de SELECT user, host, password FROM mysql.user (base mysql table user).

je voudrais aussi un SELECT version(); sur le serveur.

ça se trouve c'est un bête problème de client trop vieux qui hache le mot de passe avec l'équivalent de OLD_PASSWORD() alors que le serveur hache avec PASSWORD().

bon c'est vrai que ça ne tient pas si c'est la même machine.

comment tu désignes ton serveur mysql dans l'appli? par une source ODBC? elle est bien configurée d'une façon différente lorsque le client est sur le réseau local ou passe par un acces internet...
(au final on pourra se contenter d'utiliser cette deuxième qui fonctionnera en local et à distance)

Mon appli est en c#, je me connecte directement à travers un driver ado.net pour MySql à ma base de données. Je n'ai effectué aucune configuration de sources de données ODBC.

je ne connais pas .NET si jamais l'erreur est là ou dans un objet qui ferme la connexion dans le code trop tot je ne pourrai pas t'aider.
est-ce que tu peux infirmer les autres propositions?

Sorry j'avais pas fait de refresh de la discussion et j'ai zappé la plupart des questions !
Le select version renvoie : 5.1.41-3Ubuntu12.6
netstat --inet -l renvoie:

Citation:

---

proto recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 *:mysql *.* LISTEN
tcp 0 0 *:pop3 *.* LISTEN
tcp 0 0 *:imap2 *.* LISTEN
tcp 0 0 *:www *.* LISTEN
tcp 0 0 *:ssh *.* LISTEN
tcp 0 0 *:smtp *.* LISTEN
tcp 0 0 *:imaps *.* LISTEN
tcp 0 0 *:pop3s *.* LISTEN
udp 0 0 192.168.1.4:netbios-ns *.*
udp 0 0 *:netbios-ns *.*
udp 0 0 192.168.1.4:netbios-dgm *.*
udp 0 0 *:netbios-dgm *.*
udp 0 0 *:bootpc *.*

le select user, host sur table user
USER HOST
EG %
root 127.0.0.1
EG 192.168.1.1
debian-sys-maint localhost
root localhost
root ubuntu

---

Bon voilà je crois que j'ai tout trouvé...

Je ne pense pas que le code ferme trop tôt la connexion puisque le code est le même. En fait lorsque je lance le code avec l'adresse internet de la BDD dans la connectionstring et que je suis connecté à mon routeur, le routeur effectue une connexion directe sans véritablement passer par le web. Lorsque j'utilise un pc portable avec une carte 3G, là je suis vraiment sur le web et c'est là que je ne reçois rien après la connexion de la BDD.

Une capture wireshark sur ton serveur ubuntu permet de voir les paquets transitant sur les interfaces. du serveur de base de donnée.

Tu y as sans doute déjà penser mais dit nous ce que ça donne.

S'il n'y a pas d'interface graphique, tcpdump doit faire l'affaire.

le inet est correct, ta table user (j'aurai du écrire STRLEN(password) ) m'aurait permit de vérifier si le mot de passe est bien positionné, mais si tu utilises le compte EG,...

Juste par acquis de conscience, enlève le compte EG@192.168.1.1 comme ça tu es sur que tu passes bien par le même compte lorsque tu es en local avec ton ip box attribuée par dhcp.

Je suis dans le brouillard moi aussi.

Question bete: y a t'il un parfeu sur ton windows? Je crois que chez windows, l'os utilise des parametres différents celon la "zone de confiance" de ta machine.

Fait la capture complémentaire avec wireshark côté internet.

Si c'est du 3g, il est aussi possible qu'il y ait un problème de proxy internet "FAI" puisque d'après mes lectures il est possible que tu sautes d'ip publiques, tout en conservant la même ip privée dans le réseau du FAI. J'y crois peu vu que j'ai jamais eu à constater celà par moi même..

Bonjour, j'ai bataillé ferme avec mon serveur, car je n'ai pas pu espionner le réseau à travers la carte 3G de l'ordinateur client:aie:. Je mets le résultat du tcpdump en pièce jointe. Ce que j'ai fait c'est une connexion 3g à la BDD qui se solde par un timeout et donc je ferme la connexion. Puis j'ouvre une autre connexion d'un autre poste à travers le réseau. Cette connexion permet l'accès aux données. Il y a bien un firewall sur mon poste 3G (Bitdefender) mais j'ai attribué toutes les autorisations TCP et UDP au programme. Effectivement quand on regarde le fichier de capture on voit bien qu'il y a un souci sur la connexion 3G.
Le compte EG@192.168.1.1 a bien été "droppé".
Merci encore pour tes conseils qui me font avancer pas mal dans la connaissance du trafic réseau.

La suppression du firewall n'a rien changé à mon problème.

bonjour.

Certaines offres 3G sont bridées. Peut être que le FAI réalise un filtrage. J'ai deja vu ça dans la boite où je suis. Il a fallu prendre une offre particulière pour faire passer du vpn over 3g. As tu essayer de te connecter avec le client en ligne de commande.

De plus, certains firewalls déconnectent les sessions inactives au bout d'un certains temps.


bon courage

Je poste pour éventuellement aider quelqu'un qui rencontrerait le même problème que le mien. Il s'agit en fait d'une taille de paquets échangés trop important. Le passage du MTU de la connexion sur le serveur à 1420 a suffi à résoudre le problème. :ccool:
Merci encore pour votre aide et à bientôt