Dans son message du 16/9/2002, Patrice Karatchentzeff �crivait: > Finalement, pour conclure ce fil, je crois que la demande d'Erwan n'est > pas r�alisable dans le cas d'un p�riph�rique non physique (du moins, pas > systematique). Au fait, Erwan, tu voulais faire quoi vraiment ?
Bonjour, Je pense que Erwan et toi passez, dans une certaine mesure, � c�t� d'un point important: le module ip_conntrack_ftp s'ins�re dans la pile r�seau... Le p�riph�rique que vous �tes en train de chercher, c'est tout simplement... le r�seau ! Il est aussi physique que n'importe quel autre, qu'il s'agisse du son ou de la vid�o, mais ip_ftp_conntrack a une particularit� importante par rapport � d'autres modules qui se chargent automatiquement d�s que le p�riph auquel ils se rapportent est acc�d� : IL EST TOTALEMENT OPTIONNEL ! Il n'est donc pas possible, par essence, de le charger automatiquement... Comment en effet le noyau saurait-il qu'un acc�s au port 21/tcp (qui pour lui n'est li� � AUCUNE appli particuli�re, c'est juste un port comme un autre) correspond � un dialogue FTP et doit donc provoquer le chargement du module ip_conntrack_ftp ? En fait on est dans le cas de la poule et de l'oeuf: c'est justement ip_conntrack_ftp qui est charg� de surveiller les dialogues TCP ayant pour source ou destination le port 21, et de _comprendre_ un tant soit peu ce qui se passe (reconna�tre une commande PORT ou une commande PASV, par exemple), afin d'autoriser ou non certains paquets � passer... Le charger en cours de route reviendrait donc, dans certains cas, � couper la branche sur laquelle on est assis... :-) La seule option qui reste est donc que cette d�cision soit laiss�e � l'utilisateur/administrateur, ou � l'appli qui fait l'acc�s. Cordialement, Bruno -- -- Service Hydrographique et Oceanographique de la Marine --- EPSHOM/INF -- 13, rue du Chatellier --- BP 30316 --- 29603 Brest Cedex, FRANCE -- Phone: +33 2 98 22 17 49 --- Email: [EMAIL PROTECTED]
