[quote=“fran.b”]As tu enregistré une partie du flux ou essayé avec mplayer?
J’ai essayé et de mon coté, il n’y a pas de souci…[/quote]
avec Sid ? quel noyau ? quelle version de VLC ?
mplayer 
je n’ai jamais réussi à faire fonctionner cette merde.
Je viens encore d’essayer et il plante. Je refuse cette saloperie.
lenny avec un vlc backporté de sid compilé avec le mlultimedia 
…
Je viens de regarder le traffic:
En fait vlc inscrit la machine auprès de 224.0.0.22 dans un groupe (228.67.43.91)
puis ensuite, chez moi, c’est 212.27.38.253 qui répond et envoit le flux en UDP… mais je ne suis pas en mode routeur.
Difficile donc de comparer.
Chez moi, ça fonctionne normalement partout … sauf sur cette Sid 64 2.6.29 .
J’ai essayé de tripoter tous les règlages et il y en a un wagon sur le nouveau VLC quand on le met en mode /préférences/toutes.
Sauf qu’ici il ne s’agit pas d’un magouillage purement interne mais d’une émission en multicast. J’avais déjà constaté ce comportement en broadcast (qui peut être vue comme une forme particulière de multicast) : si un paquet est émis en broadcast sur une interface quelconque, par exemple eth0, alors il est non seulement émis vers l’extérieur, mais aussi rebouclé en interne, en quelque sorte dupliqué. Et le paquet dupliqué qui est rebouclé est vu par iptables comme s’il avait été reçu par l’interface de sortie eth0, et non l’interface de loopback.
Je ne suis pas d’accord : le paquet porte l’adresse source de la machine locale et non de la Freebox.
Il serait intéressant de vérifier si ces paquets sont effectivement émis à l’extérieur de la machine.
Concernant le pourquoi de ces paquets et de la nécessité de les accepter, je n’y connais pas grand chose en multicast et encore moins en freeplayer/multiposte/vlc, aussi me contenterai-je de me référer à cette citation bien connue attribuée à Einstein :
[quote=“PascalHambourg”]… aussi me contenterai-je de me référer à cette citation bien connue attribuée à Einstein :
Très belle preuve d’humilité. 
[quote=“PascalHambourg”]
Il serait intéressant de vérifier si ces paquets sont effectivement émis à l’extérieur de la machine.
Concernant le pourquoi de ces paquets et de la nécessité de les accepter, je n’y connais pas grand chose en multicast et encore moins en freeplayer/multiposte/vlc, aussi me contenterai-je de me référer à cette citation bien connue attribuée à Einstein :
Oui, mais moi quand je ne comprend pas ça m’énerve.
Tuy trouveras ici freeplayer.wcap une capture sur un flux freeplayer (à partir du début, le flux marche).
Le paquet 16 est intéressant (demande d’inscription à un groupe broadcast)
Le paquet 19 indique de jouer le flux et le flux lui même est une série de paquet venant de freeplayer.freebox.fr.
Il n’y a aucun traffic sur lo (d’après wireshark, y compris en ne cherchant à capturer que cela).
Par contre, ma freebox est en bridge, au contraire de Ricardo. Il faudrait qu’il fasse une capture du flux par wireshark et nous la fasse parvenir…
Ricardo, peux tu
PS: Tu peux laisser tomber le courage et taper avec les deux mains c’est plus pratique…
Je ne reprends le clavier que vers 2 :00 du mat alors il est un peu tard pour tester ça.
Je te fais ça demain fin matinée, comme ça tu l’auras après la manif 
Et moi, qu’est-ce que tu crois ?
L’adresse de groupe est justement celle du paquet multicast qui posait problème à Ricardo, qu’on retrouve d’ailleurs en position 14.
Ce sont les deux seuls paquets multicast, et ça ne répond pas à la question : pourquoi faut-il que le poste reçoive un paquet multicast qu’il a lui-même envoyé ? Et puis à quoi diable sert ce multicast puisque le flux RTSP/RTP est bel et bien transmis en unicast ?
Pourtant tu as des adresses privées. Je suppose que tu as un routeur entre ton poste et la freebox ? Quel type (vu son adresse MAC j’ai bien une idée) ? Je demande parce que ce routeur doit rediriger le flux RTSP vers le poste client, il fait ça tout seul ou tu a défini des redirections de ports ?
J’ai installé ce wireshark que je ne connais pas.
Avant de continuer et de faire des conneries,
question :
je n’ai aps de choix “any”
“capture” ==> choix = interfaces, options,start, (stop et restart en grisé), capture filters.
éventuellement, dans ‘Capture/interfaces’, j’ai mes deux ports valides : eth0 et wlan0
À toushasards, j’ai fait un enregistrement et je t’envoie ça cet AM car là, je me fais engueuler car la soupe refroidit. 
Et moi, qu’est-ce que tu crois ?
L’adresse de groupe est justement celle du paquet multicast qui posait problème à Ricardo, qu’on retrouve d’ailleurs en position 14.
Ce sont les deux seuls paquets multicast, et ça ne répond pas à la question : pourquoi faut-il que le poste reçoive un paquet multicast qu’il a lui-même envoyé ? Et puis à quoi diable sert ce multicast puisque le flux RTSP/RTP est bel et bien transmis en unicast ?[/quote]
C’est la (en fait une des) questions que je me pose…
(en fait, les règles sont
potes 212.27.38.253
fromto 212.27.38.253 tcp 245
fromto 212.27.38.253 udp 245
si tu prends le script que j’ai fait dans le fil «iptables pour les nuls»)
J’ai eu l’idée de faire la capture sur le FitPC, on voit passer le fameux paquet IGMP…
Je filtre le paquet dès que j’ai le temps (beaucoup de traffic 8M de capture…)
Ricardo: Reessaye la capture en enregistrant la totalité du bazar et en enregistrant le fichier (il doit pouvoir être ouvert avec «wireshark fichier»), la capture d’écran me laisse sur ma faim, il manque beaucoup de paquets…
J’hésitais avec un PC single-board du même fabricant. Voire un module intégré dans une boîte noire propriétaire, mais ça m’aurait étonné de ta part.
Ces règles de redirection ont un gros inconvénient, elles ne permettent pas de regarder la télé depuis un autre poste (ça ne te gêne pas forcément). Mais le suivi de connexion et le NAT de netfilter n’ont toujours pas de prise en charge du protocole RTSP en standard, donc on fait comme on peut. Il y a bien eu jusqu’à assez récemment un patchlet inclus dans le patch-o-matic-ng, mais était-il encore maintenu et compatible avec les noyaux récents ? Il faudra que je cherche pourquoi il a été retiré…
Passer ? Il traverse le routeur ?
[quote=“PascalHambourg”]
Passer ? Il traverse le routeur ?[/quote]
Non, 224.0.0.2 identifie un routeur multicast sur le réseau si je me souviens bien, c’est donc un peu comme une adresse broadcast, ça ne doit pas routé ce genre de chose… (?)
Je voulais juste dire que ça n’est pas une cuisine interne sur le réseau lo
Bon, ebn ça s’obscurcit, je ne vois aucun paquet venant d’où que ce soit en rapport avec 228.67.43.91 ou venant de 192.168.0.10, en clair c’est comme chez moi. Je vais voir si j’ai le même pbm que Ricardo en bloquant le INPUT. Ça explique peut être la différence entre les distributions si c’est une cuisine locale: le statut de ces paquets fluctue d’un noyau à l’autre peut être?
Pascal, je te fournis la partie utile de la capture de Ricardo: capture de Ricardo
Et comment voulez-vous qu’un pauvre R comme moi puisse comprendre si les cracks pataugent.
Bon, en mettant les règles
iptables -A INPUT -s 192.168.1.245 -j DROP
iptables -A INPUT -p udp -d 228.67.43.91 -j DROP
Ça se passe très bien chez moi… Remarque, j’ai une Freebox V4 non rebouté depuis des lustres.
Pas grand chose à dire de plus que vos deux captures sont similaires à un ACK près.
Oui j’ai bien pensé à une différence selon la version de noyau, mais alors pourquoi d’après Ricardo le comportement est différent en i386 et amd64 avec le même noyau 2.6.29 ?
[quote=“PascalHambourg”]Pas grand chose à dire de plus que vos deux captures sont similaires à un ACK près.
Oui j’ai bien pensé à une différence selon la version de noyau, mais alors pourquoi d’après Ricardo le comportement est différent en i386 et amd64 avec le même noyau 2.6.29 ?[/quote]
Non, Sid sur les deux maisuuu 2.6.29 en amd64 mais 2.6.26-1-686 sur le P4
je vais faire l’essai de placer le 2.6.29 sur le P4 et je donne le résultat.
EDIT :Bon ben je verrai ça dans une autre vie car ça commence à me fatiguer 
Maintenant, c’est NVIDIA qui ne veut plus s’installer sur ce putain de P4 avec le 2.6.29-1-686
[quote=“fran.b”]Bon, en mettant les règles
iptables -A INPUT -s 192.168.1.245 -j DROP
iptables -A INPUT -p udp -d 228.67.43.91 -j DROP
Ça se passe très bien chez moi… Remarque, j’ai une Freebox V4 non rebouté depuis des lustres.[/quote]
Les deux lignes ajoutées mais aucune différence : image toujours aussi étroite et trop à gauche … pour mon goût.
J’ai quand même réussi à installer cette saloperie de nvidia sur un 2.6.29-1-686
donc, là, il n’y a plus de différences entre les deux machine, sinon qu’une tourne en 64 bits et l’autre en 32.
Le noyau est le même : version 2.6.29-3
VLC = même versio aussi
ricardo@DD3:~$ apt-cache policy vlc
vlc:
Installé : 0.9.9a-2
Candidat : 0.9.9a-2
Les images qui suivent sont prises exactement en même temps sur les deux machines. Elles parlent d’elles-même.
À vous les studios ! (en fait, à moi car mon portable est un Dell studio 1737 :smt002 )
[quote=“ricardo”]donc, là, il n’y a plus de différences entre les deux machine, sinon qu’une tourne en 64 bits et l’autre en 32.
Le noyau est le même : version 2.6.29-3
VLC = même version aussi[/quote]
Et le résultat est le même sur les deux machines selon que la règle INPUT qui accepte le paquet multicast soit présente ou pas ?