Discussion :

[ternel]

Je suis arrivé il y a trois semaines dans une équipe de développement (C++ essentiellement) pour résoudre un problème vraiment peu banal

Le système complet est composé de trois appareils: une unité d'acquisition nommée UTL (Debian 5.0 Lenny), une station de commande (un tablet-pc sous Windows XP) et un petit routeur dont je ne connais plus la marque pour l'instant

Pour être plus précis, sur l'UTL tourne une application gérant la communication vers l'extérieur, nommé trans(-mission). Elle communique avec les autres modules de l'UTL, sans soucis.
Elle communique avec le routeur via un câble Ethernet, en envoyant des trames SSL (via openSSL).

L'utilisateur dispose de la station, sur laquelle sont installées les applications requises à l'interaction avec l'UTL: un serveur apache, openSSL et nos quelques applications fournissant l'interface graphique.
Il peut se connecter au routeur soit directement en Ethernet soit par Wifi.

C'est là que tout devient subtil.
Pour des raisons de sécurité, lors de son démarrage, l'UTL désactive la fonction Wifi du routeur, et si aucun message de maintient de connexion venant de la station n'est reçut dans la première minute, elle réactive ce Wifi.
Donc si la station est branchée en Ethernet, le Wifi reste éteint.

Le cycle standard de l'application est le suivant:

1. Démarrage autonome (ou presque) de l'UTL et de la station,
2. L'utilisateur utilise la station pour paramétrer la mission qu'il souhaite accomplir,
   
   • La station envoie un message nommé READY,
   • L'UTL répond par un RREADY,
   • La station envoie une demande des paramètres actuels,
   • L'UTL répond par l'envoi des dits paramètres,
   • L'utilisateur les modifie pour les besoin de la mission,
   • La station envoie les nouveaux valeurs
3. L'utilisateur démarre la mission,
4. L'utilisateur termine la mission.

Voici le moment tant attendu:
Lorsque la station est reliée par une liaison filaire, tout se passe bien.
Lorsqu'au contraire le Wifi est utilisé, le message de RREADY est refusé par la station.

Présentation des symptômes plus précis:
le module trans, qui utilise libcURL pour envoyer le RREADY, signale "ssl: couldn't create context!" (rapportée comme une erreur curl_out_of_memory...)
lorsque apache (chargé de recevoir les messages sur la sta) est remplacé par openssl en mode serveur, on voit que le message est recu mais rejeté. 11 bytes sont attendus, mais 0 sont disponibles.

Quelques logs ont été ajouté a openssl via libcurl, on obtient les événements suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
creating connection #0
testing <ip of sta>... connected
connection closed
aborting connection #0
ssl: couldn't create context! (ce dernier message est créé par curl)

Un ensemble de certificats est utilisé pour sécuriser la connexion.

Nous disposons d'une version antérieur de l'installation logicielle complète, qui est fonctionnelle. J'ai lu l'intégralité des diffs des sources des binaires que nous déployons, et je n'ai rien vu qui puissent impacter la connexion. Il n'y a d'ailleurs aucun changement concernant de trans.

Si quelqu'un a une idée, je suis preneur.

Compléments d'information technique:
versions logicielles sur l'UTL:
debian 5.0 lenny,
openssl 0.9.8g-15+lenny6,
libcurl 7.18.2-8lenny4

[ternel]

La source du problème est trouvée: une librairie compilée avec les binaires de l'UTL, mais qui n'est pas déployé au même endroit que ceux-ci, contrairement à ce que je pensais.

Reste à trouver précisément l'erreur et à la corriger.

[ternel]

La réponse est à la fois simple et douloureuse.
Le code nécessite une refonte majeure.

En effet, il suffit de modifier les déclarations de quelques fonctions pour faire disparaitre les symptomes.

Ces trois fonctions recevaient des char*, sans les modifier. En remplaçant par des const char*, tout fonctionne.
Je soupçonne qu'un appel à ses fonctions se faisait avec une chaine littérale.