[HS/2] vlc et la freebox

Jean Baptiste Favre a écrit :

Le problème concernant l'IP 228.67.43.91 viendrait de l'utilisation de
la librairie www.liv555.com qui envoie un paquet vers cette IP multicast
pour récupérer l'IP locale.

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 ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

>> Jean Baptiste Favre a écrit :

Bonjour,
Peut-être la réponse ici: http://www.gege.org/
J'ai également eu le problème: les paquets UDP arrivent bie n sur la
machine mais rien ne s'affiche.
Un petit tour dans iptables plus tard, il faut ajouter la règle suivante:

iptables -A INPUT -p udp -d 228.67.43.91 --dport 15947 -j ACCEPT

Les paquets concernés ont pour IP source la propre IP de la mach ine
client.

Tu peux m'expliquer ça? J'avoue ne pas comprendre cette derniè re règle
iptables. Ni pour -d, ni pour --dport :(

La règle est toute simple: on autorise (-j ACCEPT) en entrée de notre
machine (-A INPUT) le trafic UDP (-p udp) à destination de l'IP
228.67.43.91 (-d 228.67.43.91) avec un numéro de port destination 15 947
(--dport 15947).
Le coup de la destination m'a aussi surpris mais j'ai trouvé cela en
enregistrant le trafic sur INPUT (dernière règle avant DROP par défaut).
l'IP en question est une IP multicast, ceci explique peut-être cela.
Cordialement,
JB

Pascal Hambourg a écrit :

Jean Baptiste Favre a écrit :

Le problème concernant l'IP 228.67.43.91 viendrait de l'utilisation de
la librairie www.liv555.com qui envoie un paquet vers cette IP multica st
pour récupérer l'IP locale.

C'est quand même bien pourri comme méthode pour récupérer l'adr esse 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 logici el
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. Dans le cas où la machine possède plusieu rs
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).
Maintenant, à mon humble avis, c'est un "hack" multiplate-forme :-)
Mais c'est vrai qu'ils pourraient communiquer un peu plus dessus.

En passant une question: comment se fait-il que la réponse à ce paque t
ne passe pas comme ESTABLISHED dans Netfilter ?

Cordialement,
JB

Le 13596ième jour après Epoch,
Pascal Hambourg écrivait:

Jean Baptiste Favre a écrit :

Le problème concernant l'IP 228.67.43.91 viendrait de l'utilisation de
la librairie www.liv555.com qui envoie un paquet vers cette IP multicast
pour récupérer l'IP locale.

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 ?

Ben il prends je pense celle que la table de routage a pû assigner au
paquet en sortie.

J'aurais dû m'en douter un peu en voyant les messages de vlc disant
que l'adresse IP était invalide: 0x0 ... Et j'aurais pû aussi les
poster, histoire de simplifier la tâche.

Mais effectivement, je confirme que si c'est juste pour récup. une ip,
c'est gravement pourri comme technique !

Le 13596ième jour après Epoch,
Jean Baptiste Favre écrivait:

Jean Baptiste Favre a écrit :

Bonjour,
Peut-être la réponse ici: http://www.gege.org/
J'ai également eu le problème: les paquets UDP arrivent bien sur la
machine mais rien ne s'affiche.
Un petit tour dans iptables plus tard, il faut ajouter la règle s uivante:

iptables -A INPUT -p udp -d 228.67.43.91 --dport 15947 -j ACCEPT

Les paquets concernés ont pour IP source la propre IP de la machi ne
client.

Tu peux m'expliquer ça? J'avoue ne pas comprendre cette derniè re règle
iptables. Ni pour -d, ni pour --dport :(

La règle est toute simple: on autorise (-j ACCEPT) en entrée de notre
machine (-A INPUT) le trafic UDP (-p udp) à destination de l'IP
228.67.43.91 (-d 228.67.43.91) avec un numéro de port destination 15 947
(--dport 15947).

:) ... J'aurais dû préciser ma question... En fait, je sais à   quoi
servent les options, et comment marche iptables, mais ce que je
voulais savoir c'est d'où sortaient ces deux valeurs. IP et Port :)

Le coup de la destination m'a aussi surpris mais j'ai trouvé cela en
enregistrant le trafic sur INPUT (dernière règle avant DROP par défaut).
l'IP en question est une IP multicast, ceci explique peut-être cela.

Ce que je trouve bizarre, c'est que je ne les avais pas vues dans
/var/log/kern.log . Mais je viens de me rendre compte que ma chaîne
DROP_LOG_IN ne ... loggue plus ;) Elle devait être trop bavarde ...

Merci en tout cas.

Le 13596ième jour après Epoch,
Jean Baptiste Favre écrivait:

Pascal Hambourg a écrit :

Jean Baptiste Favre a écrit :

Le problème concernant l'IP 228.67.43.91 viendrait de l'utilisatio n de
la librairie www.liv555.com qui envoie un paquet vers cette IP multicast
pour récupérer l'IP locale.

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 logi ciel
sait-il laquelle est la bonne ?

Bien pourri je ne sais pas. En fait, le paquet envoyé à cette a dresse
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. Dans le cas où la machine possède p lusieurs
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éfau t).
Maintenant, à mon humble avis, c'est un "hack" multiplate-forme :-)
Mais c'est vrai qu'ils pourraient communiquer un peu plus dessus.

En passant une question: comment se fait-il que la réponse à ce paquet
ne passe pas comme ESTABLISHED dans Netfilter ?

Il me semble qu'en UDP, il n'est pas toujours nécessaire d'établi r une
liaison. Surtout en multicast. Mais ça fait longtemps que je n'ai pas
joué avec ça.

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= SRC2.168.0.1 DST"8.67.43.91
LEN9 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=UDP SPT947 DPT947 LEN

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.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

François TOURDE a écrit :

Le 13596ième jour après Epoch,
Jean Baptiste Favre écrivait:

Jean Baptiste Favre a écrit :

Bonjour,
Peut-être la réponse ici: http://www.gege.org/
J'ai également eu le problème: les paquets UDP arrivent b ien sur la
machine mais rien ne s'affiche.
Un petit tour dans iptables plus tard, il faut ajouter la règl e suivante:

iptables -A INPUT -p udp -d 228.67.43.91 --dport 15947 -j ACCEPT

Les paquets concernés ont pour IP source la propre IP de la ma chine
client.

Tu peux m'expliquer ça? J'avoue ne pas comprendre cette dernià ¨re règle
iptables. Ni pour -d, ni pour --dport :(

La règle est toute simple: on autorise (-j ACCEPT) en entrée de notre
machine (-A INPUT) le trafic UDP (-p udp) à destination de l'IP
228.67.43.91 (-d 228.67.43.91) avec un numéro de port destination 15947
(--dport 15947).

:) ... J'aurais dû préciser ma question... En fait, je sais à   quoi
servent les options, et comment marche iptables, mais ce que je
voulais savoir c'est d'où sortaient ces deux valeurs. IP et Port : )

Oups pardon :-)
En fait, je l'ai eue en regardant les logs de Netfilter, règle que j 'ai
ajouté en dernier dans INPUT, sachant que la politique par défa ut et DROP.
Comme VLC était la seule appli démarrée, ça devait tr ès
vraisemblablement venir de là.
Sinon, sur http://www.gege.org/, lui a trouvé ça dans les sourc es.
Chacun son truc :-)

Le coup de la destination m'a aussi surpris mais j'ai trouvé cela en
enregistrant le trafic sur INPUT (dernière règle avant DROP par défaut).
l'IP en question est une IP multicast, ceci explique peut-être ce la.

Ce que je trouve bizarre, c'est que je ne les avais pas vues dans
/var/log/kern.log . Mais je viens de me rendre compte que ma chaîn e
DROP_LOG_IN ne ... loggue plus ;) Elle devait être trop bavarde .. .

Merci en tout cas.

Pascal Hambourg a écrit :

Jean Baptiste Favre a écrit :

C'est quand même bien pourri comme méthode pour récupérer l'a dresse 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 logi ciel
sait-il laquelle est la bonne ?

Bien pourri je ne sais pas. En fait, le paquet envoyé à cette adre sse
multicast l'est avec un TTL à 0. Du coup, en retour, on doit avoir u n
message d'erreur (j'ai pas vérifié avec tcpdump) qui permet à VL C
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.6 7.43.91
LEN=39 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=UDP SPT=159 47 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 s emble
qu'il ne faut pas envoyer de message d'erreur ICMP quand la destination
du paquet original est une adresse multicast.

N'étant pas un spécialiste réseau (notamment sur le multicast), je n'ai
pas la réponse. Je ne peux que me perdre en conjectures :-)

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 pa quet
ne passe pas comme ESTABLISHED dans Netfilter ?

Si le paquet reçu est le paquet UDP multicast émis, il a l'état N EW. Si
c'était un message d'erreur ICMP, il aurait l'état RELATED et passe rait
par l'interface de loopback puisqu'envoyé de la machine à elle-mê me.

Je pense surtout après réflexion que le problème, c'est l'IP de
destination qui n'est pas l'IP locale. Donc le paquet n'est pas
considéré comme ESTABLISHED ou RELATED. Je pense même, je ferai l'e ssai,
qu'il devrait être considéré comme INVALID puisque semblant proveni r de
la machine locale mais sur l'interface externe.

Cordialement,
JB

Jean Baptiste Favre a écrit :

N'étant pas un spécialiste réseau (notamment sur le multicast), je n'ai
pas la réponse. Je ne peux que me perdre en conjectures :-)

Pas mieux. Je ne suis pas spécialiste réseau et ne connais quasiment
rien au multicast.

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.

Je pense surtout après réflexion que le problème, c'est l'IP de
destination qui n'est pas l'IP locale. Donc le paquet n'est pas
considéré comme ESTABLISHED ou RELATED. Je pense même, je ferai l'essai,
qu'il devrait être considéré comme INVALID puisque semblant provenir de
la machine locale mais sur l'interface externe.

Je ne pense pas. Pour autant que je sache, iptables et le suivi de
connexion de Netfilter se servent des adresses source et destination
uniquement pour rattacher un paquet à une connexion pour l'un et à faire
des comparaisons dans les règles pour l'autre. D'ailleurs ils ne gèrent
pas spécifiquement les broadcasts et multicasts, ce qui peut poser des
problèmes avec certaines applications. Et puis, je ne crois pas que
l'état INVALID puisse exister en UDP.

C'est plutôt la pile IP qui peut rejeter des paquets reçus avec une
adresse source jugée invalide (les "martiens"). En ce qui concerne les
paquets rebouclés et donc qui entrent avec une adresse source locale, la
pile se débrouille bien pour accepter les broadcasts qui entrent dans
cette catégorie alors on peut penser que c'est pareil pour les
multicasts "locaux".

J'ai bien essayé sur une machine, mais le paquet émis n'est pas
rebouclé. Je suppose qu'il faut préalablement "enregistrer" l'adresse
multicast pour recevoir le trafic qui lui est destiné, ce que je ne sais
faire.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org