J'ai un petit probleme car j'utilise TYPSoft FTP serveur et j'ai ZApro
comme firewall.
Le probleme est que je suis obligé de desactiver ZA parce qu'il refuse
la connection du client.
Pourtant j'ai bien ouvert 20,21 en TCP et UDP.
Quand je donne le lien vers mon serveur j'avoute pourtant bien le :21
a la fin pour obliger la connexion sur le port 21.
Seulement les client d'en face se connecte soit sur 12,68, 74,
198,235,238,241,249,250,253.......Ca se voit car mon serveur m'affin
l'IP du client + 2 chiffre a la fin (port ?) genre 80,xx,xx,xx,xx,port
D'ailleur je viens de me rendre compte a l'instant que c'est 4 chiffre
de plus. Actuelement c'est IP,13,74
Je ne sais pas comment faire.
Pouvez vous m'aider.
merci.
--
90 % des hommes politiques donnent une mauvaise
réputation aux 10 % qui restent.
data port (L-1) using the specified user data port. The direction of the transfer and the port used will be determined by the FTP service command. [...]
La RFC demande qu'on utilise CMD-1 pour le port initiateur de la connexion de données en actif. Impec. J'ai plus de doute là dessus, j'étais pas sur de moi sur ce point
mais j'avais remarqué cependant que toutes les implémentations de serveurs FTP réagissaient bien comme celà.
et le firewall devrait se contenter de connaitre l'IP du serveur et le port du client FTP fourni via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Le firewall, il suit la RFC. Si tu utilises un client qui n'est pas RFC compliant, change de client. Oui du coup si c'est écrit dans la RFC c'est bien mieux. :-)
En outre, on ne peut pas connaître le port source de la connexion de commande en actif dans la mesure où celui-ci n'est pas négocié. C'est très dommageable pour le soucis de restriction maximum qui motive l'utilisation d'un filtrage à états. Pas bien compris là? En passif non plus d'ailleurs.
Pour le canal CMD...le client prend un port haut dispo en local sur sa stack TCP en effet. Sans négociation (au niveau FTP) en dehors du three way handshake TCP quoi. une connexion TCP classique donc. En relisant je pense que tu voulais parler du canal DATA? Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont anticipables au compte goutte avec les commandes PORT et PASV respectivement... Pas très clair, si tu peux préciser ton paragraphe...merci d'avance.
On se réfère donc à la RFC, et ça nous permet de restreindre l'autorisation contextuelle à une seule et unique connexion pour le flux de données actif, et non un jeu de possibilités. Si la RFC précise que c'est séquenciel (ce que je n'ai pas vérifié)...on ne
peut donc pas paralléliser les commandes FTP qui nécessitent un retour de données, donc oui, un seul canal DATA simultanément par "contexte de connexion FTP" (contexte = IP Client, IP Serveur, Une connexion CMD FTP).. Ca evite de transformer un firewall en passoire effectivement :-)
On remarquera qu'on a un problème de ce type avec le helper IRC qui ne connait ni l'IP de la partie distante, ni l'ensemble des ports, lorsqu'une connexion DCC doit être mise en place. Et là, la RFC ne nous aide pas. En effet...
Cordialement, Laurent
data port (L-1) using the specified user data port. The direction
of the transfer and the port used will be determined by the FTP
service command.
[...]
La RFC demande qu'on utilise CMD-1 pour le port initiateur de la connexion
de données en actif.
Impec. J'ai plus de doute là dessus, j'étais pas sur de moi sur ce point
mais j'avais remarqué cependant que toutes les implémentations de serveurs
FTP réagissaient bien comme celà.
et le firewall devrait se contenter de connaitre l'IP du serveur et le
port du client FTP fourni via la commande PORT...mais bon c'ets pas plus
mal pour la sécurité)
Le firewall, il suit la RFC. Si tu utilises un client qui n'est pas RFC
compliant, change de client.
Oui du coup si c'est écrit dans la RFC c'est bien mieux. :-)
En outre, on ne peut pas connaître le port source de la connexion de
commande en actif dans la mesure où celui-ci n'est pas négocié. C'est très
dommageable pour le soucis de restriction maximum qui motive l'utilisation
d'un filtrage à états.
Pas bien compris là? En passif non plus d'ailleurs.
Pour le canal CMD...le client prend un port haut dispo en local sur sa stack
TCP en effet. Sans négociation (au niveau FTP) en dehors du three way
handshake TCP quoi. une connexion TCP classique donc.
En relisant je pense que tu voulais parler du canal DATA?
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont
anticipables au compte goutte avec les commandes PORT et PASV
respectivement...
Pas très clair, si tu peux préciser ton paragraphe...merci d'avance.
On se réfère donc à la RFC, et ça nous permet de
restreindre l'autorisation contextuelle à une seule et unique connexion
pour le flux de données actif, et non un jeu de possibilités.
Si la RFC précise que c'est séquenciel (ce que je n'ai pas vérifié)...on ne
peut donc pas paralléliser les commandes FTP qui nécessitent un retour de
données, donc oui, un seul canal DATA simultanément par "contexte de
connexion FTP" (contexte = IP Client, IP Serveur, Une connexion CMD FTP)..
Ca evite de transformer un firewall en passoire effectivement :-)
On remarquera qu'on a un problème de ce type avec le helper IRC qui ne
connait ni l'IP de la partie distante, ni l'ensemble des ports, lorsqu'une
connexion DCC doit être mise en place. Et là, la RFC ne nous aide pas.
En effet...
data port (L-1) using the specified user data port. The direction of the transfer and the port used will be determined by the FTP service command. [...]
La RFC demande qu'on utilise CMD-1 pour le port initiateur de la connexion de données en actif. Impec. J'ai plus de doute là dessus, j'étais pas sur de moi sur ce point
mais j'avais remarqué cependant que toutes les implémentations de serveurs FTP réagissaient bien comme celà.
et le firewall devrait se contenter de connaitre l'IP du serveur et le port du client FTP fourni via la commande PORT...mais bon c'ets pas plus mal pour la sécurité)
Le firewall, il suit la RFC. Si tu utilises un client qui n'est pas RFC compliant, change de client. Oui du coup si c'est écrit dans la RFC c'est bien mieux. :-)
En outre, on ne peut pas connaître le port source de la connexion de commande en actif dans la mesure où celui-ci n'est pas négocié. C'est très dommageable pour le soucis de restriction maximum qui motive l'utilisation d'un filtrage à états. Pas bien compris là? En passif non plus d'ailleurs.
Pour le canal CMD...le client prend un port haut dispo en local sur sa stack TCP en effet. Sans négociation (au niveau FTP) en dehors du three way handshake TCP quoi. une connexion TCP classique donc. En relisant je pense que tu voulais parler du canal DATA? Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont anticipables au compte goutte avec les commandes PORT et PASV respectivement... Pas très clair, si tu peux préciser ton paragraphe...merci d'avance.
On se réfère donc à la RFC, et ça nous permet de restreindre l'autorisation contextuelle à une seule et unique connexion pour le flux de données actif, et non un jeu de possibilités. Si la RFC précise que c'est séquenciel (ce que je n'ai pas vérifié)...on ne
peut donc pas paralléliser les commandes FTP qui nécessitent un retour de données, donc oui, un seul canal DATA simultanément par "contexte de connexion FTP" (contexte = IP Client, IP Serveur, Une connexion CMD FTP).. Ca evite de transformer un firewall en passoire effectivement :-)
On remarquera qu'on a un problème de ce type avec le helper IRC qui ne connait ni l'IP de la partie distante, ni l'ensemble des ports, lorsqu'une connexion DCC doit être mise en place. Et là, la RFC ne nous aide pas. En effet...
Cordialement, Laurent
Cedric Blancher
Dans sa prose, Laurent nous ecrivait :
Pas bien compris là? En passif non plus d'ailleurs. Pour le canal CMD...le client prend un port haut dispo en local sur sa stack TCP en effet. Sans négociation (au niveau FTP) en dehors du three way handshake TCP quoi. une connexion TCP classique donc. En relisant je pense que tu voulais parler du canal DATA?
Exact, j'ai fourché.
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont anticipables au compte goutte avec les commandes PORT et PASV respectivement...
Non. Le port source de la connexion de données n'est pas négocié. On ne négocie que le port destination, en actif via la commande PORT qui nous donne le port ouvert en écoute par le client, et en passif via la réponse au PASV qui nous donnera le port ouvert en écoute par le serveur. Par contre, dans aucun des deux cas, l'initiateur (le serveur en actif, le client en passif) ne déclare dans le flux de commande le port qu'il utilisera comme source de cette connexion. On doit alors se référer à la RFC pour le déduire, à partir du port affecté par la partie concernée au canal de commandes.
Si la RFC précise que c'est séquenciel (ce que je n'ai pas vérifié)...on ne peut donc pas paralléliser les commandes FTP qui nécessitent un retour de données, donc oui, un seul canal DATA simultanément par "contexte de connexion FTP" (contexte = IP Client, IP Serveur, Une connexion CMD FTP).. Ca evite de transformer un firewall en passoire effectivement :-)
FTP ne prévoit pas que plusieurs canaux de données puissent être gérés en même temps sur le même canal de commande. La non vérification de cette condittion est la base de certaines attaques visant à ouvrir des autorisations. Par exemple :
-- Je viens d'adopter une limace (elle s'appele "Chompie"), et j'ai trouve des infos sur un site qui n'a pas ete mis a jour depuis des siecles! Meme si l'auteur ne s'y interesse plus, le site garde tout son interet. -+- P in : Guide du Neuneu d'Usenet - L'êre des limaces média -+-
Dans sa prose, Laurent nous ecrivait :
Pas bien compris là? En passif non plus d'ailleurs. Pour le canal
CMD...le client prend un port haut dispo en local sur sa stack TCP en
effet. Sans négociation (au niveau FTP) en dehors du three way
handshake TCP quoi. une connexion TCP classique donc. En relisant je
pense que tu voulais parler du canal DATA?
Exact, j'ai fourché.
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports
sont anticipables au compte goutte avec les commandes PORT et PASV
respectivement...
Non. Le port source de la connexion de données n'est pas négocié. On ne
négocie que le port destination, en actif via la commande PORT qui nous
donne le port ouvert en écoute par le client, et en passif via la réponse
au PASV qui nous donnera le port ouvert en écoute par le serveur. Par
contre, dans aucun des deux cas, l'initiateur (le serveur en actif, le
client en passif) ne déclare dans le flux de commande le port qu'il
utilisera comme source de cette connexion. On doit alors se référer à la
RFC pour le déduire, à partir du port affecté par la partie concernée au
canal de commandes.
Si la RFC précise que c'est séquenciel (ce que je n'ai pas
vérifié)...on ne peut donc pas paralléliser les commandes FTP qui
nécessitent un retour de données, donc oui, un seul canal DATA
simultanément par "contexte de connexion FTP" (contexte = IP Client, IP
Serveur, Une connexion CMD FTP).. Ca evite de transformer un firewall en
passoire effectivement :-)
FTP ne prévoit pas que plusieurs canaux de données puissent être gérés en
même temps sur le même canal de commande. La non vérification de cette
condittion est la base de certaines attaques visant à ouvrir des
autorisations. Par exemple :
--
Je viens d'adopter une limace (elle s'appele "Chompie"), et j'ai trouve
des infos sur un site qui n'a pas ete mis a jour depuis des siecles!
Meme si l'auteur ne s'y interesse plus, le site garde tout son interet.
-+- P in : Guide du Neuneu d'Usenet - L'êre des limaces média -+-
Pas bien compris là? En passif non plus d'ailleurs. Pour le canal CMD...le client prend un port haut dispo en local sur sa stack TCP en effet. Sans négociation (au niveau FTP) en dehors du three way handshake TCP quoi. une connexion TCP classique donc. En relisant je pense que tu voulais parler du canal DATA?
Exact, j'ai fourché.
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont anticipables au compte goutte avec les commandes PORT et PASV respectivement...
Non. Le port source de la connexion de données n'est pas négocié. On ne négocie que le port destination, en actif via la commande PORT qui nous donne le port ouvert en écoute par le client, et en passif via la réponse au PASV qui nous donnera le port ouvert en écoute par le serveur. Par contre, dans aucun des deux cas, l'initiateur (le serveur en actif, le client en passif) ne déclare dans le flux de commande le port qu'il utilisera comme source de cette connexion. On doit alors se référer à la RFC pour le déduire, à partir du port affecté par la partie concernée au canal de commandes.
Si la RFC précise que c'est séquenciel (ce que je n'ai pas vérifié)...on ne peut donc pas paralléliser les commandes FTP qui nécessitent un retour de données, donc oui, un seul canal DATA simultanément par "contexte de connexion FTP" (contexte = IP Client, IP Serveur, Une connexion CMD FTP).. Ca evite de transformer un firewall en passoire effectivement :-)
FTP ne prévoit pas que plusieurs canaux de données puissent être gérés en même temps sur le même canal de commande. La non vérification de cette condittion est la base de certaines attaques visant à ouvrir des autorisations. Par exemple :
-- Je viens d'adopter une limace (elle s'appele "Chompie"), et j'ai trouve des infos sur un site qui n'a pas ete mis a jour depuis des siecles! Meme si l'auteur ne s'y interesse plus, le site garde tout son interet. -+- P in : Guide du Neuneu d'Usenet - L'êre des limaces média -+-
Laurent
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont anticipables au compte goutte avec les commandes PORT et PASV respectivement...
Non. Le port source de la connexion de données n'est pas négocié. On ne négocie que le port destination, en actif via la commande PORT qui nous donne le port ouvert en écoute par le client, et en passif via la réponse au PASV qui nous donnera le port ouvert en écoute par le serveur. Par contre, dans aucun des deux cas, l'initiateur (le serveur en actif, le client en passif) ne déclare dans le flux de commande le port qu'il utilisera comme source de cette connexion. Exact (quand je disais "les ports sont anticipables" je parlais des ports
destinations) mais on est dans le cadre d'une connexion TCP classique encore une fois. (à lier cependant au contexte FTP avant acceptation)...
On doit alors se référer à la RFC pour le déduire, à partir du port affecté par la partie concernée au canal de commandes. Euh ça me parait un peu arbitraire là....si du côté client j'ai plein
d'applications qui ouvrent des connexions TCP je ne vois pas trop comment on peut se permettre côté serveur de dire "le client va arriver avec le port (source CMD + 1) ou même (source CMD + X) pour être un peu plus tolérant... J'ai le droit d'ouvrir un canal CMD FTP vers un serveur, puis en parallèle d'ouvrir 50000 connexions TCP ailleurs, puis seulement de faire un GET FTP...non? (si je fais vite :-) ) Ou alors j'ai pas bien compris ce que tu voulais préciser...
FTP ne prévoit pas que plusieurs canaux de données puissent être gérés en même temps sur le même canal de commande. La non vérification de cette condittion est la base de certaines attaques visant à ouvrir des autorisations. Par exemple :
http://www.netfilter.org/security/2001-04-16-ftp.html Ok, merci pour l'info.
Cordialement, Laurent
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports
sont anticipables au compte goutte avec les commandes PORT et PASV
respectivement...
Non. Le port source de la connexion de données n'est pas négocié. On ne
négocie que le port destination, en actif via la commande PORT qui nous
donne le port ouvert en écoute par le client, et en passif via la réponse
au PASV qui nous donnera le port ouvert en écoute par le serveur. Par
contre, dans aucun des deux cas, l'initiateur (le serveur en actif, le
client en passif) ne déclare dans le flux de commande le port qu'il
utilisera comme source de cette connexion.
Exact (quand je disais "les ports sont anticipables" je parlais des ports
destinations) mais on est dans le cadre d'une connexion TCP classique encore
une fois. (à lier cependant au contexte FTP avant acceptation)...
On doit alors se référer à la
RFC pour le déduire, à partir du port affecté par la partie concernée au
canal de commandes.
Euh ça me parait un peu arbitraire là....si du côté client j'ai plein
d'applications qui ouvrent des connexions TCP je ne vois pas trop comment on
peut se permettre côté serveur de dire "le client va arriver avec le port
(source CMD + 1) ou même (source CMD + X) pour être un peu plus tolérant...
J'ai le droit d'ouvrir un canal CMD FTP vers un serveur, puis en parallèle
d'ouvrir 50000 connexions TCP ailleurs, puis seulement de faire un GET
FTP...non? (si je fais vite :-) )
Ou alors j'ai pas bien compris ce que tu voulais préciser...
FTP ne prévoit pas que plusieurs canaux de données puissent être gérés en
même temps sur le même canal de commande. La non vérification de cette
condittion est la base de certaines attaques visant à ouvrir des
autorisations. Par exemple :
http://www.netfilter.org/security/2001-04-16-ftp.html
Ok, merci pour l'info.
Mais pour le canal DATA, que ce soit en actif ou en passif, les ports sont anticipables au compte goutte avec les commandes PORT et PASV respectivement...
Non. Le port source de la connexion de données n'est pas négocié. On ne négocie que le port destination, en actif via la commande PORT qui nous donne le port ouvert en écoute par le client, et en passif via la réponse au PASV qui nous donnera le port ouvert en écoute par le serveur. Par contre, dans aucun des deux cas, l'initiateur (le serveur en actif, le client en passif) ne déclare dans le flux de commande le port qu'il utilisera comme source de cette connexion. Exact (quand je disais "les ports sont anticipables" je parlais des ports
destinations) mais on est dans le cadre d'une connexion TCP classique encore une fois. (à lier cependant au contexte FTP avant acceptation)...
On doit alors se référer à la RFC pour le déduire, à partir du port affecté par la partie concernée au canal de commandes. Euh ça me parait un peu arbitraire là....si du côté client j'ai plein
d'applications qui ouvrent des connexions TCP je ne vois pas trop comment on peut se permettre côté serveur de dire "le client va arriver avec le port (source CMD + 1) ou même (source CMD + X) pour être un peu plus tolérant... J'ai le droit d'ouvrir un canal CMD FTP vers un serveur, puis en parallèle d'ouvrir 50000 connexions TCP ailleurs, puis seulement de faire un GET FTP...non? (si je fais vite :-) ) Ou alors j'ai pas bien compris ce que tu voulais préciser...
FTP ne prévoit pas que plusieurs canaux de données puissent être gérés en même temps sur le même canal de commande. La non vérification de cette condittion est la base de certaines attaques visant à ouvrir des autorisations. Par exemple :
http://www.netfilter.org/security/2001-04-16-ftp.html Ok, merci pour l'info.
Cordialement, Laurent
Cedric Blancher
Dans sa prose, Laurent nous ecrivait :
On doit alors se référer à la RFC pour le déduire, à partir du port affecté par la partie concernée au canal de commandes. Euh ça me parait un peu arbitraire là....si du côté client j'ai
plein d'applications qui ouvrent des connexions TCP je ne vois pas trop comment on peut se permettre côté serveur de dire "le client va arriver avec le port (source CMD + 1) ou même (source CMD + X) pour être un peu plus tolérant... J'ai le droit d'ouvrir un canal CMD FTP vers un serveur, puis en parallèle d'ouvrir 50000 connexions TCP ailleurs, puis seulement de faire un GET FTP...non? (si je fais vite :-) ) Ou alors j'ai pas bien compris ce que tu voulais préciser...
C'était exactement ce genre de chose. Je ne le trouve plus dans la RFC, ce ne doit donc pas être obligatoire. Mais si c'était spécifié, le client binde deux ports dès le départ, et c'est réglé. Mais celà pose évidemment un problème de concurrence.
Les clients que je viens de regarder utilisent tous CMD+1.
-- parce que ça arriverait très vite à un plat de spaghettis dégoulinant de sauce à la dépendance non résolue. Imagine Mysql en RPM, Postgres en deb et colle dessus un Php en sources et un Apache en tgz. Vavavoum la machine ! -+- TTH in GFA : Restauration rapide ? -+-
Dans sa prose, Laurent nous ecrivait :
On doit alors se référer à la RFC pour le déduire, à partir du
port affecté par la partie concernée au canal de commandes.
Euh ça me parait un peu arbitraire là....si du côté client j'ai
plein d'applications qui ouvrent des connexions TCP je ne vois pas trop
comment on peut se permettre côté serveur de dire "le client va
arriver avec le port (source CMD + 1) ou même (source CMD + X) pour
être un peu plus tolérant... J'ai le droit d'ouvrir un canal CMD FTP
vers un serveur, puis en parallèle d'ouvrir 50000 connexions TCP
ailleurs, puis seulement de faire un GET FTP...non? (si je fais vite :-)
) Ou alors j'ai pas bien compris ce que tu voulais préciser...
C'était exactement ce genre de chose. Je ne le trouve plus dans la RFC, ce
ne doit donc pas être obligatoire. Mais si c'était spécifié, le client
binde deux ports dès le départ, et c'est réglé. Mais celà pose évidemment
un problème de concurrence.
Les clients que je viens de regarder utilisent tous CMD+1.
--
parce que ça arriverait très vite à un plat de spaghettis dégoulinant de sauce
à la dépendance non résolue. Imagine Mysql en RPM, Postgres en deb et colle
dessus un Php en sources et un Apache en tgz. Vavavoum la machine !
-+- TTH in GFA : Restauration rapide ? -+-
On doit alors se référer à la RFC pour le déduire, à partir du port affecté par la partie concernée au canal de commandes. Euh ça me parait un peu arbitraire là....si du côté client j'ai
plein d'applications qui ouvrent des connexions TCP je ne vois pas trop comment on peut se permettre côté serveur de dire "le client va arriver avec le port (source CMD + 1) ou même (source CMD + X) pour être un peu plus tolérant... J'ai le droit d'ouvrir un canal CMD FTP vers un serveur, puis en parallèle d'ouvrir 50000 connexions TCP ailleurs, puis seulement de faire un GET FTP...non? (si je fais vite :-) ) Ou alors j'ai pas bien compris ce que tu voulais préciser...
C'était exactement ce genre de chose. Je ne le trouve plus dans la RFC, ce ne doit donc pas être obligatoire. Mais si c'était spécifié, le client binde deux ports dès le départ, et c'est réglé. Mais celà pose évidemment un problème de concurrence.
Les clients que je viens de regarder utilisent tous CMD+1.
-- parce que ça arriverait très vite à un plat de spaghettis dégoulinant de sauce à la dépendance non résolue. Imagine Mysql en RPM, Postgres en deb et colle dessus un Php en sources et un Apache en tgz. Vavavoum la machine ! -+- TTH in GFA : Restauration rapide ? -+-
Laurent
Les clients que je viens de regarder utilisent tous CMD+1. Oui j'ai tjs constaté ça aussi...mais c'est vraiment le problème de la
mutualisation de la stack TCP pour toutes les applications au dessus (en plus du paramètre temps) qui fait qu'on ne peut pas garantir que le port source suivant...A la limite il aurait fallu comme tu le dis que le client reserve tout de suite un second port pour les DATA et qu'il utilise tjs le même également...là il aurait pu informer la machine distante mais bon...on dévie pas mal du message original là :-)
Cdlt, Laurent
Les clients que je viens de regarder utilisent tous CMD+1.
Oui j'ai tjs constaté ça aussi...mais c'est vraiment le problème de la
mutualisation de la stack TCP pour toutes les applications au dessus (en
plus du paramètre temps) qui fait qu'on ne peut pas garantir que le port
source suivant...A la limite il aurait fallu comme tu le dis que le client
reserve tout de suite un second port pour les DATA et qu'il utilise tjs le
même également...là il aurait pu informer la machine distante mais bon...on
dévie pas mal du message original là :-)
Les clients que je viens de regarder utilisent tous CMD+1. Oui j'ai tjs constaté ça aussi...mais c'est vraiment le problème de la
mutualisation de la stack TCP pour toutes les applications au dessus (en plus du paramètre temps) qui fait qu'on ne peut pas garantir que le port source suivant...A la limite il aurait fallu comme tu le dis que le client reserve tout de suite un second port pour les DATA et qu'il utilise tjs le même également...là il aurait pu informer la machine distante mais bon...on dévie pas mal du message original là :-)
Cdlt, Laurent
foo tche bol
On 25 Jul 2003 12:14:14 GMT, "Laurent" wrote:
Les clients que je viens de regarder utilisent tous CMD+1. Oui j'ai tjs constaté ça aussi...mais c'est vraiment le problème de la
mutualisation de la stack TCP pour toutes les applications au dessus (en plus du paramètre temps) qui fait qu'on ne peut pas garantir que le port source suivant...A la limite il aurait fallu comme tu le dis que le client reserve tout de suite un second port pour les DATA et qu'il utilise tjs le même également...là il aurait pu informer la machine distante mais bon...on dévie pas mal du message original là :-)
Cdlt, Laurent
Bon en clair pour les nuls : Ca veut dire quoi tout ca et comment que je fais moi ? Je suis un esprit simple dans un corps simple.
merci
-- - Faire une reinstall sur une install de XP, c'est comme rajouter de l'huile dans un moteur sans pour autant en faire la vidange. - Hello, je suis un Virus de signature, veuillez à bien vouloir copier ma signature à la place de la votre.
On 25 Jul 2003 12:14:14 GMT, "Laurent" <llepage@perso.free.fr> wrote:
Les clients que je viens de regarder utilisent tous CMD+1.
Oui j'ai tjs constaté ça aussi...mais c'est vraiment le problème de la
mutualisation de la stack TCP pour toutes les applications au dessus (en
plus du paramètre temps) qui fait qu'on ne peut pas garantir que le port
source suivant...A la limite il aurait fallu comme tu le dis que le client
reserve tout de suite un second port pour les DATA et qu'il utilise tjs le
même également...là il aurait pu informer la machine distante mais bon...on
dévie pas mal du message original là :-)
Cdlt,
Laurent
Bon en clair pour les nuls : Ca veut dire quoi tout ca et comment que
je fais moi ?
Je suis un esprit simple dans un corps simple.
merci
--
- Faire une reinstall sur une install de XP, c'est comme rajouter de l'huile dans un moteur sans pour autant en faire la vidange.
- Hello, je suis un Virus de signature, veuillez à bien vouloir copier ma signature à la place de la votre.
Les clients que je viens de regarder utilisent tous CMD+1. Oui j'ai tjs constaté ça aussi...mais c'est vraiment le problème de la
mutualisation de la stack TCP pour toutes les applications au dessus (en plus du paramètre temps) qui fait qu'on ne peut pas garantir que le port source suivant...A la limite il aurait fallu comme tu le dis que le client reserve tout de suite un second port pour les DATA et qu'il utilise tjs le même également...là il aurait pu informer la machine distante mais bon...on dévie pas mal du message original là :-)
Cdlt, Laurent
Bon en clair pour les nuls : Ca veut dire quoi tout ca et comment que je fais moi ? Je suis un esprit simple dans un corps simple.
merci
-- - Faire une reinstall sur une install de XP, c'est comme rajouter de l'huile dans un moteur sans pour autant en faire la vidange. - Hello, je suis un Virus de signature, veuillez à bien vouloir copier ma signature à la place de la votre.
Laurent
Bon en clair pour les nuls : Ca veut dire quoi tout ca et comment que je fais moi ? Je suis un esprit simple dans un corps simple.
merci :-))
Ben pour moi dans ta config (je connais très peu ZA), tu dois autoriser le port 21 à accueillir des connexions donc ça c'est bien...ensuite j'imagine qu'il faut que tu autorises l'application serveur FTP ("TYPSoft FTP serveur ") à sortir sur le net. Ensuite deux cas de figure : - ZA detecte que c'est du FTP (ça m'étonne qu'il ne le fasse pas) et dans ce cas, que le client distant fasse du FTP actif ou passif ça devrait fonctionner (mais je ne connais pas ZA)...et d'apres ce que tu dis ça ne marche pas ! - Le client fait du FTP passif et tente de se connecter sur un port "exotique"...malheureusement ZA n'a pas analyser la commande PASV dans le canal CMD et donc n'accèpte pas la connexion DATA sur le port exotique...Dans ce cas il faut que les utilisateurs distant configurent leur client FTP pour faire du mode FTP actif et ça devrait marcher...
J'ai pas d'autre idée là. Je t'avoue que je n'ai pas lu tout le thread en dehors de la liste d'échanges avec Cédric Blancher....donc je redis peut-être quelquechose qui a été dit....voire je (re)dis une connerie ;-)
Pour résumer : Demande à l'utilisateur qui lance le client FTP distant de forcer ce dernier à faire du mode actif et tiens nous au courant.
Cordialement, Laurent.
Bon en clair pour les nuls : Ca veut dire quoi tout ca et comment que
je fais moi ?
Je suis un esprit simple dans un corps simple.
merci
:-))
Ben pour moi dans ta config (je connais très peu ZA), tu dois autoriser le
port 21 à accueillir des connexions donc ça c'est bien...ensuite j'imagine
qu'il faut que tu autorises l'application serveur FTP ("TYPSoft FTP serveur
") à sortir sur le net.
Ensuite deux cas de figure :
- ZA detecte que c'est du FTP (ça m'étonne qu'il ne le fasse pas) et dans ce
cas, que le client distant fasse du FTP actif ou passif ça devrait
fonctionner (mais je ne connais pas ZA)...et d'apres ce que tu dis ça ne
marche pas !
- Le client fait du FTP passif et tente de se connecter sur un port
"exotique"...malheureusement ZA n'a pas analyser la commande PASV dans le
canal CMD et donc n'accèpte pas la connexion DATA sur le port
exotique...Dans ce cas il faut que les utilisateurs distant configurent leur
client FTP pour faire du mode FTP actif et ça devrait marcher...
J'ai pas d'autre idée là. Je t'avoue que je n'ai pas lu tout le thread en
dehors de la liste d'échanges avec Cédric Blancher....donc je redis
peut-être quelquechose qui a été dit....voire je (re)dis une connerie ;-)
Pour résumer : Demande à l'utilisateur qui lance le client FTP distant de
forcer ce dernier à faire du mode actif et tiens nous au courant.
Bon en clair pour les nuls : Ca veut dire quoi tout ca et comment que je fais moi ? Je suis un esprit simple dans un corps simple.
merci :-))
Ben pour moi dans ta config (je connais très peu ZA), tu dois autoriser le port 21 à accueillir des connexions donc ça c'est bien...ensuite j'imagine qu'il faut que tu autorises l'application serveur FTP ("TYPSoft FTP serveur ") à sortir sur le net. Ensuite deux cas de figure : - ZA detecte que c'est du FTP (ça m'étonne qu'il ne le fasse pas) et dans ce cas, que le client distant fasse du FTP actif ou passif ça devrait fonctionner (mais je ne connais pas ZA)...et d'apres ce que tu dis ça ne marche pas ! - Le client fait du FTP passif et tente de se connecter sur un port "exotique"...malheureusement ZA n'a pas analyser la commande PASV dans le canal CMD et donc n'accèpte pas la connexion DATA sur le port exotique...Dans ce cas il faut que les utilisateurs distant configurent leur client FTP pour faire du mode FTP actif et ça devrait marcher...
J'ai pas d'autre idée là. Je t'avoue que je n'ai pas lu tout le thread en dehors de la liste d'échanges avec Cédric Blancher....donc je redis peut-être quelquechose qui a été dit....voire je (re)dis une connerie ;-)
Pour résumer : Demande à l'utilisateur qui lance le client FTP distant de forcer ce dernier à faire du mode actif et tiens nous au courant.
