Discussion :

[ced600]

Bonjour,

Je fait un softphone SIP qui réalise un hard handover de sa station wifi actuelle vers une nouvelle.
Après le handover est un simple script supprimant la configuration IP sur la carte wifi, puis qui effectue l'attachement vers un essid connu, et reconfigure statiquement une @ IP (pas de serveur DHCP).

Je souhaite émettre des paquets SIP sur ce nouveau réseau wifi, mais pour cela il faut que je détecte la fin de l'attachement sur la station wifi et ceci rapidement.
Actuellement je fait ceci dans un thread :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
int sortie = 0;
while(sortie == 0)
{
   system("iwconfig ath0 | grep \"Access Point\" > chemin_vers_un_fichier.txt");
   /* Récupération du contenu du fichier. */
   /* Détection de la valeur d'Access Point */
   /* Si la valeur d'Access Point est une mac adresse valide (pas 00:00:00:00 ou Not Associated) je met sortie à 1*/
}
sortie = 0;

J'ai un délais moyen de 6 - 7 ms, et je cherche à le réduire, mais je ne sais pas comment.
En fait je voudrais changer de méthode et par exemple récupérer un trigger remonté au noyeau pour signaler l'attachement.

Je sais qu'avec les socket netlink je peux faire ce genre de chose, mais je ne maitrise pas le sujet. Pour tout dire, je ne travail pas seul sur le projet, et un des membres de l'équipe à travailler un peu pour faire une fonction qui détecte l'ajout d'une IP sur une interface avec NetLink, mais pour lui, NetLink n'est pas adapté pour détecter l'attachement.

Est ce quelqu'un aurait une piste ? Pas forcément une solution, mais un ou deux mots qui me permettrais de faire des recherches. Parce que "c detecter attachement reseau" cela ne donne pas grand chose sur google

Le tout est d'avoir une solution plus rapide que 6 - 7 ms, et < à 1ms si possible.

Merci d'avance pour vos réponses.

[krieg]

Salut , je n'ai pas une réponse toute faite.
j'ai l'impression que les 6-7 ms son dus au temps que ton thread
soit schedulé. N'aurais tu pas un moins d'envoyer un signal au système (ou de récupérer un signal matériel) pour que ton thread prenne la main le plus vite possible?

Je me suis peux être égaré.

[ced600]

Merci pour ta réponse, mais les 6-7 ms ne sont pas du au thread pour la simple et bonne raison que j'ai d'abord testé sans thread.

Ce temps est tout simplement du à cet ligne :

Code :

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

system("iwconfig ath0 | grep \"Access Point\" > chemin_vers_un_fichier.txt");

En fait je me suis mal exprimé, mon délais moyen correspond au délais de la commande, non pas qu'appelait system soit l'on, mais tout simplement parce que créer un fichier texte avec des données dedans prends à lui tout seul 3-4 ms.

Après en fonction de mon nombres d'itération de boucle je suis beaucoup plus long.
Mon vraie problème est que ce que j'ai fait à des bornes au niveau délais assez grande : 3 - 12 ms. Et donc dans le pire des cas, ma fonction ne détectera l'attachement wifi que 12 ms après son attachement réel.
Ce qui n'est pas top.
Si la fonction avait une réactivité constante et proche de la milliseconde cela serait mieux.
Mais pour cela il me faut une solution autre que celle que j'ai exposé, mais comme je n'en vois pas d'autre, je me suis dit que peut être quelqu'un s'est déjà penché sur le problème sur le forum.

En tout cas merci de t'être penché sur mon problème, si tu as une autre idée n'hésite pas

[souviron34]

je répondais 2 choses :

1. d'une part, utiliser les sockets directs, comme ça tu minimises le temps passé... Si tu tiens à utliiser ta commande, voir le point 2.
   
   
2. d'autre part, faire le test de la nouvelle station avant d'avoir déconnecté l'ancienne, comme ça le basculement se fait entre 2 "running connexions"..
   
   
3. Au lieu de faire appel à system et grep, ouvrir le fichier en lecture, se positionner à la fin, et détecter toute modification (avec un timer). à chaque modification, relire juste les lignes depuis la dernière posiiton et vériifier la condition du "grep"..

[ced600]

Merci pour ta réponse.

d'une part, utiliser les sockets directs, comme ça tu minimises le temps passé... Si tu tiens à utliiser ta commande, voir le point 2.

Je configure l'adresse IP de la carte manuellement sur l'interface pendant la phase d'attachement. Donc j'arriverais à binder mes sockets sans que forcément l'attachement soit fait.
Sinon je ne suis pas attaché à ma commande, c'est la seule que j'ai trouvé pour l'instant.

d'autre part, faire le test de la nouvelle station avant d'avoir déconnecté l'ancienne, comme ça le basculement se fait entre 2 "running connexions"..

Je ne suis pas sur de ce que tu veux dire par là, alors je vais juste énoncé quelque vérité sur mon projet:

1. Je n'ai qu'une seule interface wifi sur le poste qui effectue le handover, donc lorsque je suis connecté à une station je ne peut pas être connecté à l'autre.
2. La décision de handover est prise par les stations et non pas le client qui fait le handover.
3. La décision est prise grâce à des informations radios détectées par les stations de bases

Au lieu de faire appel à system et grep, ouvrir le fichier en lecture, se positionner à la fin, et détecter toute modification (avec un timer). à chaque modification, relire juste les lignes depuis la dernière posiiton et vériifier la condition du "grep"..

Heu... Pour l'instant rien d'autre que la commande dans system ne me crée et modifie le fichier. Et en soit le fichier n'est qu'un moyen pour moi de communiquer entre la commande et le programme.
Si j'avais un moyen de récupérer l'information renvoyé par la commande sans passer par un fichier, cela serait certainement mieux.
Au niveau des temps j'ai 3 - 12 ms pour la commande et - d'1 ms pour le reste.

Typiquement pour moi c'est un manque de connaissance de ma part pour pouvoir faire un programme qui écoute le trigger remonté au noyeau concernant la fin de l'attachement, si ce trigger existe. Et comme je n'ai pas de piste, pas simple de trouver de l'aide.

Je vous ai peut être tous induit en erreur en vous montrant ma solution, qui me semble est en soit à revoir entiérement et pas juste améliorer. Je sais juste en tant que membre actif dans le forum VBS que lorque l'on répond à quelqu'un on aime bien savoir ce qu'il a fait.

Donc bref en résumant :
"Comment détecter, en 1 ms maximum, qu'une interface réseau wifi à fini sa phase d'attachement (niveau 2) à un serveur possédant une antenne wifi et configuré en mode Master ?"
Sachant donc que je suis sur fedora 7 avec le noyeau de l'époque (donc pas le plus récent).

[krieg]

Salut,
iwconfig recupere les informations dans /proc/
tu peux peux-être récuperer ces informations dans ce dossier.
les fichier utilisées sont listé dans les différentes pages de man.
En espérant que cela t'aidera.

[ced600]

J'ai avancé mais j'ai encore des problèmes.

J'ai découvert qu'il faut que j'utilise les fonctions wireless pour arriver à mes fins.
La plus part des outils wireless (iwconfig, iwevent, ...) utilisent les informations issus du fichier /proc/net/wireless.

Quand je l'ouvre avec vi, je trouve une valeur status qui change en fonction de la phase de handover, et en gros lorsque je suis déconnecté elle est à 1, et lorsque je suis connecté elle est à 4.

Donc j'ai tenté de l'ouvrir dans mon programme, mais là je ne récupère rien
J'utilise une fonction prise sur la faq qui ouvre le fichier en binaire, se positionne à la fin pour récupéré la taille, et copie le contenu dans un buffer de char* à l'aide de fread.
Mais lorsque je veux afficher le contenu (printf ou puts), j'ai une erreur de segmentation, et un strlen sur le buffer me renvois 3.

D'ailleurs j'ai essayé un cp du fichier vers le bureau, mais le fichier de destination se trouve vide après la copie

Bref je ne comprends pas, d'autant que ma méthode précédente marche mal, car le driver de la carte ne met pas à zéro les informations sur lesquelles je m'appuie.
Même un network restart ne les mets pas à 0
Donc comme elles ont des valeurs cohérentes, je ne sais pas quand est ce que j'ai fait l'attachement.

Ensuite j'ai vu iwevent qui me renvois les event sur la carte réseau dont la fin de l'attachement.
Je voudrais faire pareil que iwevent mais dans mon programme, mais je ne trouve ni le code de cet outils, ni comment utilisé wireless.h qui est le header utilisé par ces outils.

Bref je galère

[souviron34]

d'abord pour ton fichier.

Si tu le lis avec vi, c'est que c'est du texte.

Par conséquent il suffit de l'ouvrir en mode normal ("r"), et d'utiliser fgets (ou fscanf) pour lire la ligne. Puis un léger rewiind, ou ftell/fseek...

[ced600]

ma fonction lit tous les fichiers texte sans problème mais pas celui là.

Je ne sais pas encore pkoi.

Mais c pas grave, j'ai trouvé mieux.

J'ai compris pkoi je n'arrivais pas à mettre le contenu de iwevent dans un fichier texte, et depuis que j'y arrive j'ai une détection bcp plus rapide.

Mais au final j'ai plein de problème.

Je fais un handover (iwconfig)
Je détecte l'attachement (iwevent)
Je configure l'adresse IP (ifconfig)
je détecte l'ajout de l'IP (netlink)
j'ajoute une route
je crée une socket UDP (un retour comme quoi elle est bien crée)
et j'envois mon message
mais celui-ci ne pars pas.

Si avant le ho je lance un ping (toutes les 1 ms) et que je ne l'arrête pas pendant la phase de ho, je vois que le premier ping repars une seconde après la fin de l'attachement.

Si je fais une pause d'une seconde et que je n'envois mon message qu'après cette pause (au même moment que le ping) le message part correctement.

Il me manque un trigger mais je ne sais pas lequel, ou ma version du noyeau est pourris, mais bon on verra cela demain.

[ced600]

Il y a longtemps que je ne travaille plus sur ce sujet.
Je crois me souvenir que mon pb d'une seconde était à la fois dû au matériel, et à la configuration de celui-ci.
Je crois que l'on a dû modifier les drivers de la carte wifi.