J'ai une Fbx V4 et je voulais essayer le multi poste avec VLC, mais =C3=A7a
ne semble pas marcher.
Quand je fais:
mplayer rtsp://mafreebox.freebox.fr/freeboxtv/stream?id=3D373
j'ai bien la vid=C3=A9o qui marche, mais VLC ne me r=C3=A9cup=C3=A8re que l=
a liste de
lecture, et pas de son ni d'image quand je choisis une cha=C3=AEne.
Je suis en testing, je pense avoir ouvert les ports qui vont bien sur
ma Debian, et VLC arrive =C3=A0 lire des fichiers vid=C3=A9os.
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 quasimen t 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 pas serait 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 prov enir 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 de s problèmes avec certaines applications. Et puis, je ne crois pas que l'état INVALID puisse exister en UDP.
Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme adresse IP source l'IP locale et comme adresse destination l'IP multicast. C'est pour cela que je pense qu'il pourrait être classé IN VALID. Exemple de log: Mar 24 12:24:26 localhost kernel: [17591169.788000] IN=eth0 OUT= MAC= SRC.0.0.10 DST"8.67.43.91 LEN9 TOS=0x00 PREC=0x00 TTL= 1 ID=0 DF PROTO=UDP SPT947 DPT947 LEN
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas e n juger. Un spécialiste de la chose pourrait-il nous éclairer ?
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 le s 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".
Donc ce multicast là se comporterait "comme" sur une interface de loopback ? ou alors j'ai pas compris ce qui est loin d'être exclu :-)
J'ai bien essayé sur une machine, mais le paquet émis n'est pas rebouclé. Je suppose qu'il faut préalablement "enregistrer" l'adres se multicast pour recevoir le trafic qui lui est destiné, ce que je ne s ais faire.
Moi itou :-s
Cordialement, JB
Pascal Hambourg a écrit :
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 quasimen t
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 pas serait
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 prov enir 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 de s
problèmes avec certaines applications. Et puis, je ne crois pas que
l'état INVALID puisse exister en UDP.
Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme
adresse IP source l'IP locale et comme adresse destination l'IP
multicast. C'est pour cela que je pense qu'il pourrait être classé IN VALID.
Exemple de log:
Mar 24 12:24:26 localhost kernel: [17591169.788000] IN=eth0 OUT= MAC=
SRC=10.0.0.10 DST=228.67.43.91 LEN=39 TOS=0x00 PREC=0x00 TTL= 1 ID=0 DF
PROTO=UDP SPT=15947 DPT=15947 LEN=19
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas
d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas e n
juger. Un spécialiste de la chose pourrait-il nous éclairer ?
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 le s
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".
Donc ce multicast là se comporterait "comme" sur une interface de
loopback ? ou alors j'ai pas compris ce qui est loin d'être exclu :-)
J'ai bien essayé sur une machine, mais le paquet émis n'est pas
rebouclé. Je suppose qu'il faut préalablement "enregistrer" l'adres se
multicast pour recevoir le trafic qui lui est destiné, ce que je ne s ais
faire.
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 quasimen t 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 pas serait 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 prov enir 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 de s problèmes avec certaines applications. Et puis, je ne crois pas que l'état INVALID puisse exister en UDP.
Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme adresse IP source l'IP locale et comme adresse destination l'IP multicast. C'est pour cela que je pense qu'il pourrait être classé IN VALID. Exemple de log: Mar 24 12:24:26 localhost kernel: [17591169.788000] IN=eth0 OUT= MAC= SRC.0.0.10 DST"8.67.43.91 LEN9 TOS=0x00 PREC=0x00 TTL= 1 ID=0 DF PROTO=UDP SPT947 DPT947 LEN
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas e n juger. Un spécialiste de la chose pourrait-il nous éclairer ?
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 le s 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".
Donc ce multicast là se comporterait "comme" sur une interface de loopback ? ou alors j'ai pas compris ce qui est loin d'être exclu :-)
J'ai bien essayé sur une machine, mais le paquet émis n'est pas rebouclé. Je suppose qu'il faut préalablement "enregistrer" l'adres se multicast pour recevoir le trafic qui lui est destiné, ce que je ne s ais faire.
Moi itou :-s
Cordialement, JB
Pascal Hambourg
Jean Baptiste Favre a écrit :
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.
Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme adresse IP source l'IP locale et comme adresse destination l'IP multicast. C'est pour cela que je pense qu'il pourrait être classé INVALID.
Je répète que le suivi de connexion de Netfilter, qui classe les paquets dans l'état NEW, ESTABLISHED,RELATED ou INVALID, ne fait aucune vérification de la validité des adresses source et destination d'un paquet. Et le traitement du suivi de connexion est identique pour les paquets reçus et les paquets émis localement.
Les raisons pour classer un paquet dans l'état INVALID sont notamment : - segment TCP correspondant à une connexion existante mais dont le numéro de séquence ne correspond pas ou ne respectant pas la séquence de synchronisation SYN,SYN/ACK,ACK, - message d'erreur ICMP ne correspondant pas à une connexion existante - réponse ICMP (echo reply par exemple) ne correspondant pas à une requête existante...
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas en juger.
Je suppose (mais ne peux que supposer) que c'est lié au fait que le paquet vu en entrée a été rebouclé en interne et n'est jamais passé par l'interface ethernet.
-- 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 with a subject of "unsubscribe". Trouble? Contact
Jean Baptiste Favre a écrit :
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.
Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme
adresse IP source l'IP locale et comme adresse destination l'IP
multicast. C'est pour cela que je pense qu'il pourrait être classé INVALID.
Je répète que le suivi de connexion de Netfilter, qui classe les paquets
dans l'état NEW, ESTABLISHED,RELATED ou INVALID, ne fait aucune
vérification de la validité des adresses source et destination d'un
paquet. Et le traitement du suivi de connexion est identique pour les
paquets reçus et les paquets émis localement.
Les raisons pour classer un paquet dans l'état INVALID sont notamment :
- segment TCP correspondant à une connexion existante mais dont le
numéro de séquence ne correspond pas ou ne respectant pas la séquence de
synchronisation SYN,SYN/ACK,ACK,
- message d'erreur ICMP ne correspondant pas à une connexion existante
- réponse ICMP (echo reply par exemple) ne correspondant pas à une
requête existante...
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas
d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas en
juger.
Je suppose (mais ne peux que supposer) que c'est lié au fait que le
paquet vu en entrée a été rebouclé en interne et n'est jamais passé par
l'interface ethernet.
--
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
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.
Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme adresse IP source l'IP locale et comme adresse destination l'IP multicast. C'est pour cela que je pense qu'il pourrait être classé INVALID.
Je répète que le suivi de connexion de Netfilter, qui classe les paquets dans l'état NEW, ESTABLISHED,RELATED ou INVALID, ne fait aucune vérification de la validité des adresses source et destination d'un paquet. Et le traitement du suivi de connexion est identique pour les paquets reçus et les paquets émis localement.
Les raisons pour classer un paquet dans l'état INVALID sont notamment : - segment TCP correspondant à une connexion existante mais dont le numéro de séquence ne correspond pas ou ne respectant pas la séquence de synchronisation SYN,SYN/ACK,ACK, - message d'erreur ICMP ne correspondant pas à une connexion existante - réponse ICMP (echo reply par exemple) ne correspondant pas à une requête existante...
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas en juger.
Je suppose (mais ne peux que supposer) que c'est lié au fait que le paquet vu en entrée a été rebouclé en interne et n'est jamais passé par l'interface ethernet.
-- 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 with a subject of "unsubscribe". Trouble? Contact
