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 ?
Je suppose que tu parles de cette règle ?
Je ne l’ai pas ajoutée sur le P4 puisque que tout fonctionnait sans ça.
J’essaierai ensuite mais auparavant, j’ai fait la comparaison point par point sur les paramètres = rien, tout est strictement identique.
MAIS
je viens de découvrir une différence entre les deux images :
fenêtre de l’image proprement dite (à grossir pour s’en rendre compte), en haut à gauche :
P4_qui_va_bien ---- = VLC (XVIDEO output)
Portable_qui_va_mal = VLC (X11 output)
J’ai cherché dans /outils/préférences/video/sortie
Sur les deux machines, le choix natif est “prédéfini” mais tous les choix sont présents, dont "sortie video extension XVideo"
J’ai mis ce choix sur le P4, “enregistrer” et rien n’a changé, image toujours bonne et même entête de fenêtre.
J’ai fait de même sur le portable mais rien n’a changé non plus, toujours cette image étroite et aucun affichage différent sur l’entête de fenêtre.
D’après l’info donnée sur le fenêtre de choix, j’en déduit qu’il me manque ptet un module de sortie ou que ce module n’est pas présent en 64 bits ou pour ma catrte graphique ?
info-bulle :
module de sortie utilisé par VLC
Le comportement par défaut est de choisir autoimatiquement
le meilleur module disponible
C’est ce mot “disponible” qui m’interpelle.
est-ce que lsmod peut donner une idée 
ou comment savoir si ce module est présent
Salut,
Quel est le pilote de ta carte graphique ?
En fait, il faut que ta CG puisse utiliser la sortie vidéo Xv.
Je crois avoir lu dans un autre sujet que tu as une carte ATI récente.
Si tu as installé le driver proprio FGLRX, la commande suivante va modifier ton xorg.conf pour utiliser Xv.
Un redémarrage du serveur X et ça devrait être bon.
Si tu n’as rien installé, tu dois avoir le pilote libre radeonhd par défaut.
De ce que j’ai lu ici http://www.x.org/wiki/radeonhd#head-901971f6b63b85bed069b4e2ccc56ccc47c29a98, Xvideo est désactivé par défaut.
J’ai parcouru le man de radeonhd mais n’ai rien trouvé de clair pour activer Xv avec ce pilote.
Attention toutefois, avec le noyau 2.6.29, les pilotes ati libres ne fonctionnent correctement avec certaines cartes que si le paquet décrit ici
http://packages.debian.org/search?keywords=firmware-linux&searchon=names&suite=all§ion=all&sourceid=mozilla-search
est installé.
Merci de toutes ces infos, on va étudier ça.
De toutes façons, j’ai en effet l’impression que le 2.6.29 est le responsable de beaucoup de mes désagréments.
Je viens de l’installer sur mon vieux P4 et il m’a “réduit au silence” mon parefeu.
Je viens juste de me rendre compte (iptables-save) que je n’avais plus rien 
J’ai remis un parefeu et là, je n’ai même pas d’image du tout, même déformée.
La suite plus tard.
Je teste tout.
Bon, tout est redevenu “normal” sur le P4 = image parfaite avec exactement le même noyau (sauf 32 bits), exactement les mêmes règles parefeu et exactement la même version de VLC que sur le portable.
@ Talogue :
aticonfig = commande inconnue sous debian.
J’ai bien vu que ça existait sous buntu mais pas ici.
Je vais essayer de modifier xorg à la main.
EDIT :
Pas mieux en rajoutant ça mais est-ce ce qu’il faut ???
Section "Device"
Identifier "Configured Video Device"
overlay-type “Xv”
La commande “aticonfig” vient avec le driver FGLRX. Du moins jusqu’à l’avant dernière version de ce driver.
Je suis passé au driver libre radeon. Alors je ne peux pas vérifier pour le pilote proprio actuel.
Le but de cette commande est de rajouter dans le xorg.conf une ligne activant la sortie Xv pour le pilote propriétaire.
J’essaie de retrouver cette ligne…
EDIT : Cela fonctionnait encore le mois dernier …
Rajouter dans la section device de xorg.conf les lignes suivantes :
Option "VideoOverlay" "on"
Option "OpenGLOverlay" "off"
Valable avec le fglrx
RE-EDIT : je ne sais toujours pas quel pilote tu utilises pour ta carte graphique ?
Ben dans lsmod, voilà ce qui correspond à la video :
uvcvideo
v4l1_compat
v4l1_compat_ioctl32
Si la commande aticonfig n’existe pas c’est que fglrx n’est pas installé chez toi.
Normalement, avec une carte ati récente, le système utilise (à vérifier) par défaut le driver libre radeonhd.
Ce lien explique comment configurer xorg.conf pour pouvoir notamment utiliser la sortie vidéo Xv.
http://wiki.x.org/wiki/radeonhd%3Ar6xx_r7xx_branch
En gros il faut un kernel 2.6.30 ou bien récupérer une version de développement de drm.
A toi de voir … 
Maintenant, tu peux toujours essayer sur une sid de base, de faire uniquement la modif du xorg.conf expliquée à la fin du lien.
Chez moi, sur un carte plus ancienne tournant avec le pilote libre radeon, cela fonctionne très bien.
EDIT : cat /var/log/Xorg.0.log | grep radeonhd devrait te dire si le pilote radeonhd est bien chargé.