Jean Baptiste Favre a écrit :
C'est quand même bien pourri comme méthode pour récupérer l'adresse IP locale. Il y a des moyens plus propres. D'ailleurs, quelle adresse locale dans le cas où la machine en a plusieurs, et comment le logiciel sait-il laquelle est la bonne ?Bien pourri je ne sais pas. En fait, le paquet envoyé à cette adresse multicast l'est avec un TTL à 0. Du coup, en retour, on doit avoir un message d'erreur (j'ai pas vérifié avec tcpdump) qui permet à VLC d'obtenir l'adresse locale.
Ça ne correspond pas au log iptables mentionné sur www.gege.org :IPTABLES REJECT : IN=eth1 OUT= MAC= SRC=192.168.0.1 DST=228.67.43.91 LEN=39 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=UDP SPT=15947 DPT=15947 LEN=19
Apparemment le paquet reçu est le paquet multicast lui-même qui est rebouclé, comme lors de l'émission d'un broadcast. AMA le TTL sert juste à éviter qu'il soit inutilement routé vers l'extérieur. Il me semble qu'il ne faut pas envoyer de message d'erreur ICMP quand la destination du paquet original est une adresse multicast.
Dans le cas où la machine possède plusieurs adresses, même pas peur puisque le paquet ne sort que par une seule interface (a priori l'interface définie pour la route par défaut).
Et si justement le serveur RTSP n'est pas joignable via l'interface définie pour la route par défaut mais via une autre interface ? Ne serait-il pas préférable d'utiliser les fonctions de socket pour récupérer l'adresse source utilisée pour envoyer la requête en TCP au serveur RTSP ?
Maintenant, à mon humble avis, c'est un "hack" multiplate-forme :-)
Probablement, je ne vois que cette explication.
En passant une question: comment se fait-il que la réponse à ce paquet ne passe pas comme ESTABLISHED dans Netfilter ?
Si le paquet reçu est le paquet UDP multicast émis, il a l'état NEW. Si c'était un message d'erreur ICMP, il aurait l'état RELATED et passerait par l'interface de loopback puisqu'envoyé de la machine à elle-même.