CoolRaoul

Pas clair tes manips, Possible de donner des détails plus précis? (du style "je lance telle appli", "je clique sur tel icone", etc ...)

Attention, les "*" a l'intérieur des douples quotes sont pris littéralement. Par conséquent: rm -rf "boxi 2013-0"* ou même: rm -rf boxi*2013-0* Doute confirmé! Pour crunch, commencer par mettre "echo --" devant le "rm" pour vérifier, exemple: echo -- rm -rf "boxi 2013-0"* Si c'est ok, tu balance la purée avec le "rm"

Tu stocke les 10 dernières années de logs de connexions d'un opérateur mobile ou quoi??? (ou tu es sous-traitant de la NSA pour gérer les archives mail de google ...) bien entendu, juste ne pas pas utiliser "+" comme séparateur mais espace

Je me demande bien quelle est l'appli qui crée un nombre aussi faramineux de fichiers et dossiers, mais bon la n'est pas le sujet... Te reste alors la solution de sauvegarder les dossiers que tu compte conserver (en espérant qu'ils ne présentent pas une volumétrie similaire), de réinitialiser le volume contenant les dossier à supprimer et d'y restaurer ta sauvegarde

Double ou simple quote ne devrait pas faire de différence dans ce cas pourtant. Pour ne pas avoir à garder ta session ouverte à surveiller le rm tu peux procéder ainsi (pas indispensable le renommage mais ça permet de ne plus avoir de problèmes avec les espaces ensuite): mv 'boxi 2012-12-17 21;00;12' a_supprimer suivi de: nohup rm -rf a_supprimer & La suppression va continuer en tache de fond, ça prendra le temps qu'il faudra, tu pourras revenir plus tard vérifier que le dossier "a_supprimer" n'est plus là.

Quelle est le message d'erreur ? Peux-tu nous donner copie de la commande utilisée? Normalement ça devrait marcher avec: rm -rf "boxi 2012-12-17 21;00;12"Peut-être n'as tu mis qu'un seul espace là ou le nom de dossier en a deux?

Probablement tous ceux qui utilisent le DDNS, ça doit donc faire du monde en effet!

Bud77 a donné la réponse à cette question 2 messages plus haut **EDIT** "1 message plus haut" et avec les détails maintenant!

N'oublie pas de désactiver la corbeille aussi, ça peut améliorer les choses.

Si tu te sens d'utiliser la ligne de commande, activer ssh et supprimer "a la main" apres s'être connecté de cette façon. Sinon, il est possible que ça se passe avec moins de douleur en ftp. Autre piste: désactiver provisoirement la corbeille sur les dossiers partagés dans lequels tu veux faire les suppressions.

Ma bascule vient de s'effectuer, mon forfait est un forfait entreprise avec l'option "Business pour Smartphone" (ne me demandez pas se que cela signifie) Et le test échoue toujours

C'est un forfait orange entreprise, géré par ma boite. En plus je dois basculer de forfait dans la journée, je n'ai pas l'intitulé du type de forfait.

Pour compléter la matrice des cas de tests, j'ai eu la possibilité ce matin de me connecter sur un autre wifi privé que le mien et dans cette configuration la connexion VPN PPTP aboutit avec succès. Donc le problème est bien localisé chez Orange. Reste à comprendre pourquoi, étant donné que mes traces montrent bien que le flux GRE n'est pas filtré.

Compléments: Suis tombé sur d'autres témoignages disant que la Freebox V5 n'est *pas* VPN Passthrough, tel que celui-la: http://forum.hardware.fr/hfr/WindowsSoftware/autoriser-vpn-freebox-sujet_213402_1.htm Mais comme ça date un peu peut-être que ça a été implémenté depuis dans le firmware V5 (et a fortiori V6)

Résumons: en 3G tcpdump voit bien passer le traffic "GRE" dans les 2 sens, donc ce n'est pas Orange qui bloque. Mais la connexion échoue. (me faudrait trouver quelqu'un de suffisamment compétent pour analyser ma capture). via freewifi je ne vois que des paquets GRE sortants: serait-il possible que free filtre ce protocole dans le cas du wifi "communautaire"? sur mon réseau local en wifi ça fonctionne (c'est quand même la moindre des choses, mais on conviendra que l'utilité pratique de cette configuration est discutable :-> ) en OpenVPN ça passe dans toutes les situations. Enfin, pour aller plus avant avec cette histoire de "natting" du protocole "GRE" je pense avoir trouvé l'explication définitive ici: http://think-like-a-computer.com/2011/09/28/vpn-passthrough/ En pratique, un routeur adsl ne sait pas nativement gérer les VPN ("Both PPTP and IPsec VPNs don’t work with NAT natively") Pour que cela fonctionne il est nécessaire qu'il implémente ce que l'on appelle "VPN Passthrough" (et plus spécifiquement dans le cas qui me pose problème, le "PPTP passthrough". J'imagine que tous les routeurs suffisamment récent (y compris les Freebox) implémentent désormais ce système. Me reste plus qu'a comprendre pourquoi, alors que ni GRE et TCP/1723 sont apparemment bloqués, la connexion échoue chez moi. je ne dispose pour cela que des messages syslog pppd et ma capture tcpdump.

Je continue a avancer Si j'en croie ce qui est écrit ici, VPN PPTP derrière freebox V5, hors DMZ point de salut: "De toute manière le PPTP c'est fichu pour moi, la freebox ne redirige que les protocole TCP et UDP, pas de GRE sauf si je mets mon serveur dans la DMZ." A noter que c'est quand meme contradictoire avec mon test en connexion 3G ou j'ai bien vu du traffic GRE dans les deux sens, comme quoi rien n'est simple

Avec le NAT en DMZ, je vois bien passer le traffic sur le protocole "GRE" (dans les deux sens) donc ce n'est pas Orange qui filtre mais ça échoue toujours: fserv> tcpdump proto gre 12:21:42.607288 IP fserv > 193.253.141.153: GREv1, call 25893, seq 0, length 41: LCP, Conf-Request (0x01), id 1, length 27 12:21:42.747571 IP 193.253.141.153 > fserv: GREv1, call 1408, seq 0, length 40: LCP, Conf-Request (0x01), id 1, length 26 12:21:42.747887 IP fserv > 193.253.141.153: GREv1, call 25893, seq 1, ack 0, length 28: LCP, Conf-Reject (0x04), id 1, length 10 12:21:45.607692 IP fserv > 193.253.141.153: GREv1, call 25893, seq 2, length 41: LCP, Conf-Request (0x01), id 1, length 27 12:21:45.969963 IP 193.253.141.153 > fserv: GREv1, call 1408, seq 1, length 40: LCP, Conf-Request (0x01), id 1, length 26 etc ... Note: pour que tcpdump comprenne faut ajouter la ligne gre 47 GRE # Generic Routing Encapsulation à /etc/protocols A noter: lors du meme test mais avec le téléphone connecté en freewifi (considéré donc comme réseau wifi externe) tcpdump sur le protocole "GRE" ne voit que des paquets *sortants*, pas les réponses donc (malgres la config DMZ) Va comprendre!

Mouais.. faudra que je demande a mes collègues spécialiste au bureau parce que je suis toujours perplexe: le NAT dynamique (celui implémenté dans les routeurs et BOX ADSL) ) à besoin de s'appuyer les ports pour savoir router les paquets entrants vers le bon équipement et ne pas Et le protocole GRE ne contient pas de concept de port. Lorsque l'on fait du NAT pour faire communiquer un réseau local avec internet par l'intermédiaire d'une IP externe unique le PAT est inévitable, c'est bien expliqué ici: http://blog.boson.com/bid/53313/NAT-and-PAT-What-s-the-Difference Faire du NAT sans faire de PAT impliquerai de n'utiliser que des addresses enregistrées sur son réseau local ("In order to use traditional NAT in this scenario, you would need to purchase a registered IP address for each host on your internal network.") Autre référence; http://kb.radware.com/questions/2999/A+Note+about+PPTP%2C+NAT+and+Linkproof As GRE is an IP based connection, it can not traverse dynamic NAT. Dynamic NAT performs port translation and assumes Layer 4 whereas GRE uses Layer 3 information PS: je viens de consolider mon test wifi, contrairement à ce que je pensait ça ne marche pas à partir d'un autre réseau wifi que le mien ce qui semblerait indiquer qu'en effet il s'agit bien d'une histoire de routage. Vais mettre le NAS en DMZ sur la box le temps de valider tout ça

Ca reste quand même obscur pour moi: si le protocole est au même niveau que TCP et UDP, par quelle magie une box ADSL serait capable de deviner vers quel équipement du réseau local rediriger les paquets de ce type puisque seuls TCP et UDP peuvent être explicitement routés via la table de redirection de ports?

"GRE": là tu me parle chinois! Je vais peut-être un peu temporiser: le 1er juillet je dois basculer vers un nouveau forfait (toujours chez Orange), on verra si ça coince toujours et si c'est le cas faudra que je contacte le service client. S'agissant d'un forfait entreprise, ça serait étonnant que le VPN soit bloqué volontairement (d'autant plus étrange qu'OpenVPN ne l'est pas!)

Comprend toujours pas: quand mon téléphone est connecté à un réseau wifi (pas forcément le mien hein!), pour arriver sur mon NAS le flux réseau va bien passer par l’adresse externe de ma box! Pas exactement pourtant puisque en sniffant le traffic IP (avec la commande "tcpdump") je vois bien passer du trafic sur le port 1723 (et dans le deux sens qui plus est) lors de mes essais en 3G, si le port était bloqué je n'aurais que des timeouts, et de plus on voit bien dans "/var/log/messages" que le dialogue s'établit avant de se retrouver bloqué. Me demande si ça ne serait pas une histoire de MTU.

Ben non, pas forcément. De toutes façon je viens de faire le test en 3G avec un *autre* téléphone et sur ce dernier ça se connecte. Le problème n'est donc pas coté NAS, mais je ne comprend pas ou ça coince. **EDIT** Je viens de tomber la dessus (suis chez orange), me demande si ce n'est pas le même probleme: http://entraide.orange.fr/assistance/messages/index/8959/iphone-vpn-pptp-bloque.html

Damned, je le savais en plus! J'ai du avoir une fuite de neurones hier.

Meme setup, En fait ça fonctionne lorsque je suis connecté à un réseau wifi mais pas en mode 3G, franchement chelou donc..

s/blocahe/blocage/ Possible ou pas?