Ensuite tu regardes dans les logs noyau (dmesg, /var/log/kern.log…) les paquets qui atteignent la règle LOG avant d’être bloqués par la politique par défaut lorsque tu essaies de regarder la télé.
Rien
Vraiment rien dans les logs du noyau ?
Là je ne comprends pas, parce si c’est iptables qui coince, alors tout paquet non accepté devrait être loggué.
[quote=“ricardo”]
6231 8449K ACCEPT all – any any freeplayer.freebox.fr anywhere state NEW,RELATED,ESTABLISHED[/quote]
Tous les paquets sont passés par là donc n’ont pas été bloqués. Cela veut dire que ça n’est pas le INPUT qui coince.
C’est sur ta machine locale… Vraiment curieux ton histoire. C’est cohérent avec le fait qu’il n’y ait rien dans les logs… C’est quoi qui lance ton parefeu??
[quote=“fran.b”][quote=“ricardo”]
6231 8449K ACCEPT all – any any freeplayer.freebox.fr anywhere state NEW,RELATED,ESTABLISHED[/quote]
Tous les paquets sont passés par là donc n’ont pas été bloqués. Cela veut dire que ça n’est pas le INPUT qui coince.
C’est sur ta machine locale… Vraiment curieux ton histoire. C’est cohérent avec le fait qu’il n’y ait rien dans les logs… C’est quoi qui lance ton parefeu??[/quote]
C’est d’autant plus bizarre qu’avec exactement les mêmes règles de parefeu et exactement la même version de VLC, ça passe sur la Sid du P4 (mais en 32 bits)et pas sur celle du portable (en 64 bits)
Le portable lui-même ne peut pas être en cause car
ça fonctionne :
Sur une kubuntu (mais je crois qu’il n’y a pas de parefeu installé car je ne l’ai jamais configurée)
Sur une Lenny avec parefeu (mais pas la même version de VLC)
et bien sûr, sur cette même Sid qui me casse les c$=+(&%$£ (mais sans parefeu)
Le parefeu est exactement celui du fil :
http://forum.debian-fr.org/viewtopic.php?f=8&t=1901&start=0
avec ces règles complètes :
[code]ricardo@Dell-sid:~$ sudo iptables-save
[sudo] password for ricardo:
Generated by iptables-save v1.4.3.2 on Wed Apr 29 00:37:14 2009
*filter
:INPUT DROP [3:213]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4333:762642]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 31336 -j ACCEPT
-A INPUT -j LOG
COMMIT
Completed on Wed Apr 29 00:37:14 2009
Generated by iptables-save v1.4.3.2 on Wed Apr 29 00:37:14 2009
*nat
:PREROUTING ACCEPT [1:60]
:POSTROUTING ACCEPT [1:60]
:OUTPUT ACCEPT [519:31332]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
Completed on Wed Apr 29 00:37:14 2009
Generated by iptables-save v1.4.3.2 on Wed Apr 29 00:37:14 2009
*mangle
:PREROUTING ACCEPT [4416:3208613]
:INPUT ACCEPT [4416:3208613]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4333:762642]
:POSTROUTING ACCEPT [4336:762855]
COMMIT
Completed on Wed Apr 29 00:37:14 2009
Generated by iptables-save v1.4.3.2 on Wed Apr 29 00:37:14 2009
*raw
:PREROUTING ACCEPT [4416:3208613]
:OUTPUT ACCEPT [4333:762642]
COMMIT
Completed on Wed Apr 29 00:37:14 2009
ricardo@Dell-sid:~$[/code]
Suggestions:
Essaye de voir en changeant la politique de INPUT puis FORWARD (uniquement à chaque fois puis les 2) à ACCEPT pour isoler le problème.
Sinon, met la politique à ACCEPT partout, fais un
iptables -A INPUT -j LOG
et une petite session de freeplayer pour voir comment sont les paquets…
Ça resserre encore les recherches car FORWARD en ACCEPT seul = pas de changement.
Replacé FORWARD en DROP et mis INPUT en ACCEPT = ça fonctionne.
Remis en DROP = Niet !
Il s’agit donc bien d’une règle INPUT à modifier ou à ajouter, non ?
Ce serait logique, mais dans ce cas la règle LOG devrait enregistrer les paquets en question avant qu’ils soient traités par la politique par défaut puisque tu n’as aucune règle avec DROP ou REJECT susceptible de bloquer un paquet avant : soit il est accepté par une règle, soit il tombe dans la politique par défaut.
Juste pour être sûr, une règle LOG en début de chaîne INPUT enregistre bien quelque chose ?
[quote=“PascalHambourg”]Ce serait logique, mais dans ce cas la règle LOG devrait enregistrer les paquets en question avant qu’ils soient traités par la politique par défaut puisque tu n’as aucune règle avec DROP ou REJECT susceptible de bloquer un paquet avant : soit il est accepté par une règle, soit il tombe dans la politique par défaut.
Juste pour être sûr, une règle LOG en début de chaîne INPUT enregistre bien quelque chose ?[/quote]
Sois plus explicite car je suis totalement nul
Voilà un exemple de ligne (il y en a des millions) qu’on peut voit dans kern.log quand on fait une maœuvre quelconque avec VLC
Ce n’est pas très causant pour moi.
Que veux-tu que je fasse concrètement 
EDIT :
autre différence entre cette machione et le P4 qui fonctionne : le wifi sur le portable et pas de wifi sur le P4.
C’est intéressant. L’adresse de destination 228.67.43.91 est de type multicast. Par contre 192.168.0.10 c’est ta machine, il me semble ? Donc même si c’est dans INPUT c’est un paquet multicast qu’elle aurait elle-même envoyé, d’où l’absence d’adresse MAC. Il me semble avoir déjà vu ça avec l’émission en broadcast. Par contre je ne pense pas qu’il soit nécessaire de les accepter, mais tu peux ajouter une règle pour tester, on ne sait jamais…
EDIT : D’autres semblent avoir eu des résultats avec
[quote=“PascalHambourg”]C’est intéressant. L’adresse de destination 228.67.43.91 est de type multicast. Par contre 192.168.0.10 c’est ta machine, il me semble ? Donc même si c’est dans INPUT c’est un paquet multicast qu’elle aurait elle-même envoyé, d’où l’absence d’adresse MAC. Il me semble avoir déjà vu ça avec l’émission en broadcast. Par contre je ne pense pas qu’il soit nécessaire de les accepter, mais tu peux ajouter une règle pour tester, on ne sait jamais…
EDIT : D’autres semblent avoir eu des résultats avec
iptables -A INPUT -p udp -d 228.67.43.91 --dport 15947 -j ACCEPTBINGO 
Maintenant, j’aimerais bien un cours à la portée d’un nul concernant cette dernière action. 
Ensuite, je passerai à autre chose … :smt002
En gros si j’ai bien compris ce qu’a dit Pascal, vlc effectuerait un envoi en streaming à lui même; il ouvre un adresse multicast qu’il alimente (les paquets viennent donc de ta machine) et il va lire cette adresse (et donc les paquets sont reçus sur le INPUT. Je croyais que quoi qu’il arrive, les magouillage interne à la machine avait lieu sur le loopback (lo)?
J’ai bien compris?
[quote=“fran.b”]En gros si j’ai bien compris ce qu’a dit Pascal, vlc effectuerait un envoi en streaming à lui même; il ouvre un adresse multicast qu’il alimente (les paquets viennent donc de ta machine) et il va lire cette adresse (et donc les paquets sont reçus sur le INPUT. Je croyais que quoi qu’il arrive, les magouillage interne à la machine avait lieu sur le loopback (lo)?
J’ai bien compris?[/quote]
Ben j’avais la même déduction que toi en pensant que tout ce qui venait de chez moi était autorisé … de fait, avec les règles générales.
C’est pour ça que je ne comprends pas pourquoi il faille de nouveau le spécifier
EDIT :
je pense à un essai que je vais faire :
si je passe en wifi, ce n’est plus 192.168.0.10 mais — .12
en principe donc, ça ne devrait plus fonctionner
J’essaie !
En fait, il faut s’inscrire à un routeur multicast qui est sans doute la freebox.
C’est sans doute la méthode utilisée par le freebox en mode routeur: Elle ouvre à la demande d’un flux une adresse multicast et il suffit de s’y inscrire pour recevoir les paquets, ce que fait vlc. Ça veut dire que deux ordinateurs devraient pouvoir suivre la même émission télé en même temps.
Ça explique aussi pourquoi ça passe par l’interface réseau et pas par le loopback: parce que c’est effectivement le cas, le flux vient en fait de la freebox (c’est logique en fait)
[quote=“fran.b”]En fait, il faut s’inscrire à un routeur multicast qui est sans doute la freebox.
C’est sans doute la méthode utilisée par le freebox en mode routeur: Elle ouvre à la demande d’un flux une adresse multicast et il suffit de s’y inscrire pour recevoir les paquets, ce que fait vlc. Ça veut dire que deux ordinateurs devraient pouvoir suivre la même émission télé en même temps.
Ça explique aussi pourquoi ça passe par l’interface réseau et pas par le loopback: parce que c’est effectivement le cas, le flux vient en fait de la freebox (c’est logique en fait)[/quote]
1/ Logique, je veux bien mais alors pourquoi ça fonctionne sans cette ligne sur Lenny de la même machine et sur Sid du P4
2/ Suite de l’EDIT dernier message :
en wifi, ça ne fonctionne pas et ça, c’est logique.
Question :
suis-je obligé de faire une seconde ligne avec '192.168.0.12’
ou puis-je “concaténer” la 1ère ligne et, si oui, comment
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPTdevrait convenir. Mais j’aimerais que Pascal confirme que j’ai bien compris le pourquoi du comment, je peux être complètement à coté de la plaque.
pour ta ligne … 0.0/24, c’est bon, ça fonctionne pour les deux.
J’attends aussi la confirmation de Pascal avant d’entamer la deuxième question. Je ne veux pas ouvrir un second fil car le titre est valable là aussi.
Dis toujours, on verra bien…
Ben il s’agit de la dimension de l’image qui est “maigre”, bloquée contre la paroi gauche de l’écran et pratiquement en noir et blanc.
Le son, lui, est bon.
Comme pour le problème précédent, ce n’est pas le cas avec Lenny et Kubuntu sur le portable ni avec la Sid du P4, où tout fonctionne correctement.
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…