CoolRaoul

Lorsque le VPN est actif, l'interface n'apparait pas dans la colonne autoriser/refuser de la conf firewall?

Ca reste un peu vague: panneau de conf -> dossier partagé -> sélectionner "homes" -> privileges ->configuration des privileges , c'est bien ça? Si oui, la config par défaut est uniquement le compte "admin" en lecture/écriture et rien pour les autres (ce qui ne doit pas les empêcher d'accéder au pseude-partage privé "home" normalement. Ah voila qui devient intéressant .. Essaie déjà (je sais ça a l'air un peu c**) désactiver/réactiver la fonction "service d’accueil utilisateur"

Il doit apparaitre dans le voisinage réseau, dans file station et ainsi de suite comme un partage a part entière sous le nom "home".

Tu veux que l'accès à chacun des sous-dossiers de ton dossier "stockage" soit réservé exclusivement à un utilisateur, c'est bien ça?

Modif que tu as effectué par l'intermédiaire de ... ?

En complément de ce qui précède: Les droits par défauts de "/volume<n>/home" sont normalement: drwxr-xr-x 4 root root Pas besoin d'assigner de privilèges aux comptes non admins sur le partage "homes" pour accéder a leur pseudo-dossier "home"

Quels étaient les droits du folder avant et apres ta modif ?De quelle façon as-ty fait cette modif? Avec le panneau de conf-> Dossier partagé ->privileges, avec file station ou un bon vieux "chmod" des familles en ligne de commande? "je" est un compte administrateur ou non?

Et ça explique pourquoi le scan de port (qui utilise ton IP Publique et pas celle du VPN) a donné la réponse que le port 22 était fermé ("isn't responding on port 22")

Constates-tu l'anomalie uniquement avec filestation ?

Non, c'est le site distant qui se connectes sur ta box. Sauf qu'il à écrit que non:

Va sur cette page http://www.t1shopper.com/tools/port-scan/ A coté de "Scan this list of port numbers" saisir "22" et juste a coté cliquer "scan" quel est le résultat?

N'aurais-tu pas configuré la Freebox avec l'IP du NAS en DMZ? Les grands esprits se rencontrent

Si on prend en compte l'ensemble du code demande/réponse on aboutit à do { $query=":04030000FF1810D2rn"; $socket->send($query); print FH "demande envoyéen"; if (my @handles = $selection->can_read($timeout)) { # des données sont arrivées sur le socket my $handle=shift(@handles); $data = <$handle>; }; } until ($data); (reste à améliorer le traitement des erreurs, et éventuellement un compte de "retries" pour ne pas partir dans une boucle infinie en cas de défaillance du convertisseur RS232)

Limite HS mais tant pis: dans quel but utiliser l'aggregation de lien? A moins d'avoir des dizaines de postes clients connectés et transférant des données simultanément sur le NAS, j'ai du mal à comprendre. A mon avis architecture complexe => complexité de diagnostic (comme on le constate ici) (au passage ça aurait été plus sympa de nous donner toutes ces infos des le départ, on aurait probablement tout de suite proposé de faire le test en direct sur une seule patte)

Solution, à mon avis plus élégante, utilisant IO::Select Ajouter au début du script: use IO::Select; my $timeout=2; # secondes puis juste après l'initialisation du socket: my $selection = IO::Select->new($socket); Enfin, code de lecture de la socket avec timeout: if (my @handles = $selection->can_read($timeout)) { # des données sont arrivées sur le socket my $handle=shift(@handles); $data = <$handle>; } else { # si on arrive ici, alors la lecture du socket # n'a rien reçu avant l'expiration du timeout # a toi de décider comment traiter le cas.. }

Le code est relativement simple, et indépendant des fonctionnalités de IO::Socket. Le bloc "eval" positionne un "watchdog" local autour de la fonction "sysread" La sortie du bloc va se faire dès que l'une des conditions suivantes est réalisée: le timer à expiré (valeur en secondes de la variable "timeout") la lecture du socket à réussi la lecture du socket à échoué sur une autre erreur Suffit donc de faire la meme chose en remplaçant ta ligne "$data=<$socket>;" grosso modo par quelque chose du genre de: my $timeout=2; # secondes eval { local $SIG{ALRM} = sub { die "alarmn" }; alarm $timeout; $data=<$socket>; alarm 0; }; if ($@) { die unless $@ eq "alarmn"; # autre erreur # sinon ici timeout atteint .... } else { # ici lecture socket reussie si $data != "" .... }

Je t'ai trouvé ça: http://stackoverflow.com/questions/4517034/perl-set-read-timeout-in-client-socket il y a peut-être des solutions plus élégantes, mais si ça marche après tout ...

Tu as *déja* ouvert un fil sur ce sujet précis. Inutile de copier/coller à l'infini tes mêmes explications dans différents threads.! Ca commence à tourner à l'obsession. A part pXy, tu es très probablement le *seul* à considérer ce que tu décris comme un dysfonctionnement (j'aimerai bien savoir d'ailleurs quel est cet "ancien NAS" dont il parle qui saurait gérer cette fonctionnalité?). N'es-tu pas interpellé par le fait que personne d'autre que moi ait eu la patience de te répondre? Comme je l'ai déjà fait, je reconnais bien volontiers, avoir initialement fait une confusion, croyant à un réel dysfonctionnement (je croyais me souvenir que les partages non accessibles n'étaient pas visibles mais en fait non). Mais depuis, j'ai pu constater mon erreur, en renouvelant mes tests. J'ai pu alors arriver à la conclusion que le comportement constaté est strictement conforme à la documentation. Si tu veux effectivement cacher la présence de certains dossiers, tu pourras toujours les déplacer dans un dossier "père" intermédiaire sur lequel les droits de lecture sont réglés uniquement pour les utilisateurs/groupes de ton choix, voila tout. PS: tu pourrais observer, en prenant le temps de lire quelques unes de mes autre interventions sur le forum, que d'habitude je m'efforce d'assister les membres avec le maximum de patience, d'écoute et de détails. Mais la, tu as réussi à épuiser toute mes réserves dans chacun de ces trois domaines. Félicitations. Et maintenant, je vais sur le champ me désabonner de ces deux fils, histoire de ne plus être tenté de réagir sur cette polémique stérile.

Pas la moindre idée, mais peut-être traiter un seul problème à la fois serait plus efficace

Ce n'est que repousser le probleme, la taille de ton /tmp est conforme (pareil pour moi). Des qu'il va réapparaitre, essaie de regarder la date et l'heure de création de ce "indexdb" et de te rapeller ce que tu as fais à ce moment là

Damned, c'est inexplicable ce qui t'arrive.

Ce sont les deux octets du port alloué pour la connexion data en mode passif: 216 << 8 + 241 = 55538. Serait intéressant que tu nous montre ce qui ce passe en mode "*non passif*" vers le NAS et en mode *passif* vers la freebox (et inutile de d’embêter avec les screenshots, un simple copier/coller en mode texte est suffisant). Surtout pas, c'est déjà suffisamment compliqué comme ça! PS: 192.68.44.30, tu nous confirmes que c'est bien l'IP du NAS? Peux-tu donner celle de ton PC stp?

Bon, on a bien avancé alors.

Bien entendu, tu n'as pas oublié de déplacer "mapiscine.pl" dans /usr/local/bin au passage?

En tout cas commence par mettre la ligne PATH en début du script shell pour utiliser le perl optware et pas le perl syno (comme j'ai déja dit, celui-la m'a fait des trucs franchement étranges). Autre chose, je trouve la ligne: ((perl /usr/local/etc/mapiscine.pl) & echo $! > /var/run/mapiscine.pid &) un peu tarabiscotée avec tout ces "&" et ces sous-shells imbriqués. Je ferai comme cela plutôt (et ainsi plus besoin de "/opt/bin" dans le PATH): /usr/local/etc/mapiscine.pl <&- & # pourquoi pas /usr/local/bin ? echo $! > /var/run/mapiscine.pid (Pas oublier le chmod +x de "/usr/local/etc/mapiscine.pl") Dernière remarque, dans le perl tu fais: open(FH,">>logmapiscine"); Sans savoir quel est le répertoire courant, puisque ni le script shell ni le script perl de fait de "cd", ajouter un "cd /tmp" dans le shell ne peut pas faire de mal sinon tu n'est pas maitre de la localisation du fichier "logmapiscine" ***EDIT*** et essaie de remettre la ligne "exec" pour voir