CoolRaoul

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

Lancé au démarrage (tu ne nous a pas dit comment mais ça ne change fondamentalement pas grand chose) l’environnement est minimum, et c'est le perl syno ("/usr/bin/perl", qui m'a souvent provoqué des problèmes louches) et pas celui d'optware qui va être utilisé. Pour forcer l'utilisation du perl optware: mettre le bon PATH *dans* le script (PATH=/opt/bin:/bin:/usr/bin) S'assurer aussi que le script est lancé *apres* que le "mount -bind" de "/opt" soit effectué (démarrage optware). Egalement, il est fort possible que la base de données ne soit pas encore démarrée lorsque le script est lancé au boot. Sinon, pour comprendre pourquoi le log ne se créée pas, faudrait que tu explique quelle méthode tu utilises pour le démarrage auto du script.

Son *nom* sera visible mais, si les droits l'interdisent, son contenu ne le sera pas! Depuis le début tu entretiens la confusion entre "voir le *nom* du dossier" et "accéder au *contenu* du dossier" (en tout cas c'est ce que les gens qui te lisent risquent de conclure, vu comment tu présentes la chose). Ecrire "dès qu'on a un compte sur le Nas d'une manière ou d'une autre on arrive à voir les dossiers / sous dossiers" laisse entendre que DSFile permettrait de cour-circuiter la sécurité des dossiers, ce qui est bien évidemment faux: il se comporte strictement de le même façon que n'importe quel gestionnaire de fichiers sur n'importe quel système d'exploitation. J'ai déjà ?p=1319181316 , prenant le temps de décortiquer tous les détails. Il est peut-être temps d'arréter de relancer ce sujet dans plusieurs fils différents.

Récupérer le contenu du flux en format texte (avec wget par exemple): $ wget -nv -O - http://www.tv-radio.com/station/fip_mp3/fip_mp3-128k.m3u #EXTM3U #EXTINF:fip_mp3 http://mp3.live.tv-radio.com/fip/all/fiphautdebit.mp3 2013-04-08 13:35:21 URL:http://gisv3.tv-radio.com/station/fip_mp3/fip_mp3-128k.m3u [78/78] -> "-" [1] Et utiliser l'URL contenu dans le flux ("http://mp3.live.tv-radio.com/fip/all/fiphautdebit.mp3" ici par exemple) à la place.

Eviter notepad: il crée des fichiers avec des fins de ligne de type dos/windows (crlf), notepad++ est plus approprié (mais ça ne gène pas Apache normalement) ansi vs utf8 ne change rien au fichier ici puisque il ne contient que des caractères non accentués. Sinon, pour savoir ou et pourquoi ça coince éditer le fichier "/usr/syno/apache/conf/httpd.conf-user" remplacer #ErrorLog /var/log/httpd-error-user.log ErrorLog /dev/null par ErrorLog /var/log/httpd-error-user.log #ErrorLog /dev/null Relancer apache comme cela: env - /usr/syno/etc/rc.d/S97apache-user.sh restart Recharcher l'url ".../doc" et aller voir quelle est l'erreur dans "/var/log/httpd-error-user.log"

Puisque ce n'est pas la faute du script, faudrait poster dans un autre fil, sinon tes questions risquent de passer inaperçues Celui-ci par exemple:

Essayer de désactiver provisoirement le script et de faire des enregistrement avec l'EPG standard pour vérifier si ça vient du script (ce qui m'étonnerait) ou pas.

Le compte 'admin' ne doit pas être utilisé en connexion ligne de commande, utiliser root a la place.

Tu penses que son NAS s'est *déja* fait pirater?

Ben tu avais un dossier "indexdb" dans /tmp qui bouffait toute la place de la partition, apparu fin février sans doute suite a un composant DSM ou autre parti en vrille. le "rm" l'a supprimé et ton problème est résolu. Maintenant, savoir ce qu'il s'est passé il y plus d'un mois sur ton NAS...