RoboTux a écrit :
Comme ce module n'est pas inclus dans les noyaux standards, il faudra probablement appliquer le patch rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau, compiler le noyau et l'installer. Ensuite :C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme free s'y mette, ça pourrait devenir intéressant de le fournir en standard.
Je doute que l'équipe de développement du noyau se préoccupe des freenautes. Le patch sera inclus dans le noyau standard quand il sera jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre qui sont désormais intégrés depuis le 2.6.14.
Il y a moyen d'utiliser module-assistant sinon ?
Aucune idée, je ne connais pas. Je me contente de patcher les sources "en dur", de configurer les options et de compiler.
modprobe ip_conntrack_rtsp iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Cette règle iptables devrait de toute façon déjà être présente en tête de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a aussi des restrictions en sortie.Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le freeplayer qui initie la connexion vers la freeboite ?
Ajouter NEW dans cette règle reviendrait à accepter à peu près n'importe quoi en entrée, sauf les paquets INVALID. Je ne pense pas que ce soit le but recherché.
D'après ce que je sais, le player établit une connexion TCP sortante de contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP sortante (qui utilise un port fixe, je ne sais plus lequel).
Par contre je ne sais pas comment ça se passe pour afficher avec la Freebox de la vidéo stockée sur le client.