Re: [Tsp-devel] RE: Stub server sur leon2 Rtems

[Eric Noulard]

Le 10/03/08, Stéphane ARQUER<address@hidden> a écrit :
> L'erreur avait été capturée avec grmon c'est pourquoi il y a une différence
>  de message.
>  Ce problème étais lié à un paramétrage du fichier linkcmds qui sert lors de
>  la compilation.
>  Ce n'est plus la cas maintenant, l'application sub_server se lance et reste
>  en attente de connexion.
>  Seul le client tsp_request_generic avec les requêtes
>  tsp_request_filtered_information ou tsp_request_information qui renvoie un
>  résultat.
>  Ce que les traces montrent c'est que je suis bloqué dans
>  tsp_stream_sender.c:268 , l'appel à
>  sock->hClient = accept(sock->socketId, NULL, &Len);
>  ne reviens jamais .

Alors il faut regarder avec tcpdump/ethereal/wireshark côté client pour voir
si la demande de connection à la socket part ou pas:

La réponse du provider au request open est (d'après tes traces):

Debug||/home/arquers/TSP/tsp-0.8.3-Source-Rtems/src/core/ctrl/tsp_provider.c##TSP_provider_request_sample_init##527:
ANSWER SAMPLE INIT data_address = 'rtems_host:1024'

donc le client devrait essayer de se connecter i.e. ouvrir une socket
vers 'rtems_host' (donc il doit savoir trouver son @IP)
au port 1024.

Soit dit en passant 1024 me parait un peu bas?
N'est-ce pas justement la limite des ports privilégiés TCP?
Si oui est-ce 1024 inclu ou exclu?
Si ça se trouve le client n'a pas les droits suffisants pour ouvrir le
port 1024?
encore que normalement c'est en écoute que c'est interdit pas en ouverture....

La trace tcpdump/ethereal/wireshark côté client nous dira si le client tente
de se connecter ou pas?


-- 
Erk