- État Confirmé
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Critique
- Priorité Haute
- Basée sur la version 4.9.1
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
4
- Fbx16135550 (31/03/2025)
- nbanba (29/03/2025)
- Quedal (28/03/2025)
- joel (28/03/2025)
- Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par nbanba - 28/03/2025
Dernière modification par nbanba - 05/04/2025
Ouverte par nbanba - 28/03/2025
Dernière modification par nbanba - 05/04/2025
FS#40173 - Problème passive mode FTP local
Bonjour
De mon côté le passage en 4.9.1 ne corrige pas le problème de FTP passif sur l’accès local:
Le mode actif fonctionne mais pas le mode passif
$ . loginfbx $ get_fbx_api system | jq .result.firmware_version "4.9.1" $ ftp freebox@fbx.fbx.lan Connected to fbx.fbx.lan. 220 Welcome to Freebox FTP Server. 331 User name okay, need password. Password: 230 User logged in, proceed. Remote system type is UNIX. Using binary mode to transfer files. ftp> passive off Passive mode: off; fallback to active mode: off. ftp> ls 200 Command Okay. 150 File Status OK. drwxr-xr-x 4 freebox freebox 80 Mar 27 08:48 .. drwx------ 12 freebox freebox 4096 Feb 27 2019 1000G drwxr-xr-x 24 freebox freebox 4096 Mar 26 18:06 FBX24T 226 Closing data connection. ftp> passive on Passive mode: on; fallback to active mode: off. ftp> ls 229 Entering extended passive mode (|||2020|) ftp: Can't connect to `192.168.100.254:2020': Connexion refusée ftp>
EDIT 20250404:
Voici la configuration FTP
Accès local FTP uniquement (Pas AUTH TLS avant LOGIN)
Accès public désactivé
$ get_fbx_api ftp/config | jq
{
"success": true,
"result": {
"enabled": true,
"allow_anonymous": false,
"remote_domain": "fbx.xxxxxxxxx.net",
"username": "freebox",
"port_data": 60000,
"port_ctrl": 21,
"weak_password": false,
"allow_remote_access": false,
"allow_anonymous_write": false
}
}
EDIT 20250405:
Le mode PASSIF fonctionne par contre quand l’accès distant est activé et que le passif mode également (avec un port définit dans freeboxOS), soit avec cette configuration:
$ get_fbx_api ftp/config/ | jq
{
"success": true,
"result": {
"enabled": true,
"allow_anonymous": false,
"remote_domain": "fbx.********.net",
"username": "freebox",
"port_data": 60000,
"port_ctrl": 21,
"weak_password": false,
"allow_remote_access": true,
"allow_anonymous_write": false
}
}
Exemple avec un transfert de 600+ GB:
ftp> get dd.test Chargement du répertoire /FBX24T/ depuis le cache (LC_TIME=fr_FR.UTF-8) Recherche de fbx.********.net Trying fbx.********.net:21 (8x.xxx.xxx.xx7) Connecté sur fbx.********.net:21 220 Welcome to Freebox FTP Server. AUTH TLS 234 Proceed with negotiation. SSL connection established using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384) PBSZ 0 200 Command Okay. PROT P 200 Command Okay. USER freebox 331 User name okay, need password. PASS xxxx 230 User logged in, proceed. FEAT SYST 215 UNIX Type: L8 TYPE I 200 Command Okay. CWD /FBX24T/ 250 directory changed to /FBX24T/ PWD 257 "/FBX24T/" Changement réussi du répertoire local vers /mnt/bck/test EPSV 229 Entering extended passive mode (|||60000|) RETR /FBX24T/dd.test 150 File Status OK. SSL data connection established using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384) / [======================================================================================>] @ 375065,73KB/s 226 Closing data connection. Transfert réussi de /FBX24T/dd.test à 375882,46 ko/s Changement de mode réussi de /mnt/bck/test/dd.test en 744 Changement réussi de l'horodatage de /mnt/bck/test/dd.test ftp>
Donc le PASSIF mode ne fonctionne pas sur le FTP LOCAL mais il fonctionne sur le FTPS DISTANT quand celui-ci est actif et qu’un port passif à été définit dans FreeboxOS
Cordialement
nbanba
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Bonjour,
Je confirme, problème toujours présent sur ma freebox Delta.
Bonjour,
La version 4.9.1 , n"a pas corrigé les problèmes de connexion de ma camera IP de vidéosurveillance au serveur FTP de la box Ultra ( connexion Ethernet filaire a la box)
Plus aucun accès possible sue ce soit en passive mode ou non.
Tout fonctionnait correctement avant la mise a jour 4.9.0 depuis plus d'un an.
Cordialement
megoine
Pareil pour moi, freebox delta V4.9 et V4.9.1 toujours le même résultat le FTP ne fonctionne plus…
Bjr,
La V4.9.1 n'a aucunement résolu le pb de la "FS 40131", qui a été fermée (?).
Le transfert FTP camera Netatmo vers disque Freebox révolution est encore HS, bien que cela était OK avant.
La non visualisation du disque Freebox ds l'explorateur W10 est toujours d'actualité.
Cdlt
Bonjour,
Je rencontre le meme souci. Depuis la version 4.9.0 mon systeme de domotique jeedom envoyait un backup sur ma freebox révolution puis ma pop quand j'ai changé d'offre. Depuis la maj citée précédemment l'opération se sole par un echec. La maj 4.9.1 n'a pas résolu ce probleme. Le probleme semble venir du port 2020 alors que nous étions sur le 21. Malgré ce changement dans mes paramètres cela na rien changé.
Bonjour
@MadjestiK:
Je reprend le commentaire du précédent ticket dans lequel je tente d'expliquer ce qu'il se passe: https://dev.freebox.fr/bugs/task/40131#comment187984
FTP actif : pour transférer 1 fichier le client se transforme en serveur et c'est le serveur qui upload/download le fichier sur/depuis le client (ce mode est outdated depuis la fin des années 1990)
FTP passif: pour transférer 1 fichier le client fait une commande PASV et le serveur lui renvoi une ip et un port (dédié à ce transfert) sur lequel le client doit se connecter pour upload/download le fichier sur/depuis le serveur
Ici la requête PASV du client échoue avec un connection refused sur l'ip+port passif transmis par le serveur et sur lequel le client doit établir la connexion pour envoyer des fichiers
Donc en fait le FTP écoute toujours sur le port 21 qui est son port de contrôle servant pour envoyer les commandes FTP.
En mode actif, le client dit au serveur sur quel port le serveur doit se connecter (le client se transforme en serveur) et le serveur envoi(ou récupère) les données sur l'IP et le port que le client à précisément transmis pour ce transfert
En mode passif, le serveur dit au client sur quel autre port que le port 21 le client doit se connecter pour récupérer (ou envoyer) les données.
Ici, en mode passif le serveur FTP de la Freebox envoi le port 2020 au client ⇒ le client essaye donc d'établir une connexion sur le port 2020 de l'IP de la Freebox, et c'est cette connexion qui échoue.
C'est le BUG qui est constaté et c'est l'objet de ce ticket.
Ce type d'erreur est généralement dut soit à un lack de configuration du serveur FTP, soit à un problème de firewall.
En effet, quand on héberge un serveur FTP, le firewall de la machine hôte de ce serveur FTP doit pouvoir ouvrir dynamiquement et à la demande les ports passifs envoyés au client FTP par le serveur lors de la transaction de passage en passif mode: PASV.
Pour ça, sur les linux moderne on utilise généralement un système s'appelant le "connection tracking" permettant au firewall de réaliser cette opération (voir "Netfilter Conntrack Helpers": https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers).
@MadjestiK: De votre côté n'essayez pas d'ouvrir des ports sur la Freebox, ça ne fonctionnera pas et surtout vous risquer d'ouvrir des flux autorisant des accès depuis internet vers des machines du réseau locales.
J'espère vous avoir un peu plus éclairés sur l'incident rencontré ici.
Cordialement
nbanba
Bonjour
@mmakassikis:
Ce problème est très gênant notamment pour la vidéosurveillance où la durée de l'incident (supérieur à 15j) commence à dépasser les durées de rétentions.
Serait il possible d'avoir un 4.9.1.1-rc1 fixant juste ce ticket ?
Merci
Cordialement
nbanba