CoolRaoul

Selon la formulation ça semble *réservé* aux zones "moyennement denses", une grande ville (zone dense pas définition) n'est pas éligible alors?

Et sinon, personne n'aurait une idée de la signification de cette limitation de l'option aux "ZMD (zones moyennement denses)" ?

Gratuite si ça n'a pas changé: https://www.freenews.fr/freenews-edition-nationale-299/fibre-optique-125/loption-ip-fixe-finalement-disponible-freebox-fibre-zmd "Il suffit d’en faire la demande pour se voir attribuer gratuitement une IPv4 complète, sous un délai d’environ 30 minutes." Par contre ca ne semble pas être disponible partout: "pour les abonnés Freebox fibre en ZMD (zones moyennement denses)"

Sur l'interface d'administration de Freebox OS, section "Configuration IPV6":

En redéfinissant un nouvel APN en IPV6 ça semble OK: Voici la conf que j'ai appliquée:

10% des clients en IPV6 seulement en 2017: https://www.nextinpact.com/brief/ipv6-active-pour-10---des-clients-mobiles-orange-et-sosh-426.htm ils se pressent à tout petit pas

Orange aussi Ah bon, pas d'IPV6 chez eux alors?

Je ne l'ai pas activé "ce site est inaccessible" ERR_ADDRESS_UNREACHABLE je vais désactiver complètement le firewall du NAS pour voir Pareil, comme si la Freebox filtrait les connexions (alors qu'elle n'intègre pas de firewall) **edit** Un élément intéressant à ajouter au dossier: dès que je bascule mon téléphone sur le WIFI, ca passe en utilisant ces mêmes addresses IPV6 globales Filtrage au niveau du réseau mobile Orange alors?

SSH, dans un navigateur Android?

Si je la met entre crochets, le client android (Juice SSH) me dit "adresse invalide"

Vu vos réponse, comment expliquer que ma connexion ne passe pas?

Free ayant forcé IPV6 dans la dernière mise à jour de ses box sous Freebox OS, j'ai décidé de tester un peu la connectivité externe. J'ai provisoirement ajouté une règle entrant de type autorisant sans exception les connexions sur le port SSH (j'aime vivre dangereusement) A partir de mon mobile, connecté en réseau 3G, je tente de me connecter en ssh via l’adresse IPV6 allouée à mon NAS en scope "global" La connexion est refusée (confirmé par un tcpdump en ligne de commande qui ne vois rien passer). J'avais pourtant lu qu'en IPV6 la Freebox était transparente pour les connexions entrantes. C'est plus le cas où j'ai loupé une étape?

Sur les box de la génération précédente (V6 et Mini), non seulement il semble bien que non, mais depuis la dernière mise à jour Freebox IPV6 est activé de force.

Le paquet que j'utilise se nomme seulement "Drive" mais il est bien de Synology aussi: Je ne connais pas ce "Drive/Cloud"

Euh... Je ne comprend pas la différence 🤔

@StephB Un paquet WOL ("magic packet") est de type *broadcast* et n'est par conséquent visible que par les équipements connectés au même réseau. Les équipements connectés au sous-réseau du VPN (en général different du subnet LAN) sont les seuls qui vont voir passer la trame WOL et ceux-ci sont forcément déjà éveillés. Voila pourquoi j'ai indiqué la nécessité de disposer d'une box ou routeur faisant proxy WOL. Dans ce cas le paquet WOL unicast entrant sur la patte WAN est converti en paquet broadcast sur la patte LAN. Et ce n'est pas une règle de routage (avec une ip fixe en destination) qui résoudra le pb: un broadcast est obligatoire puisque la machine à réveiller n'a pas encore d'adresse IP tant qu'elle est dans cet état (à moins de bidouiller avec des entrées statiques permanentes dans la table ARP de la box mais là ça devient de la grande sorcellerie)

Petit retour d'expérience. Ma base Keepass de référence est stockée sur mon NAS dans un dossier géré également par Drive. J'y accède de diverse manière: en WebDav sur SSL depuis mon lieu de travail en SFTP depuis mon smartphone. en SMB depuis mon réseau local (PC et tablette) via le dossier partagé Drive sur le PC de ma mère (quand je passe faire du support informatique à domicile). Tout cela fonctionne et se synchronise sans problème dans tous les sens. Sachant que dans Keepass, que ce soit la version Windows que la version Android, la fonction "enregistrer" est en fait une synchronisation bi-directionnelle il n'y a pas trop de risque de perdre une modif. En outre, le fait que ma base soit stockée dans Syno Drive me fait implicitement bénéficier du versioning intégré ce qui permet un éventuel retour arrière rapide en cas de fausse manip.

Sur mon smartphone Android j'utilise cette appli qui me satisfait: https://play.google.com/store/apps/details?id=co.uk.mrwebb.wakeonlan Dans la mesure ou votre box sait faire du proxy Wake on LAN (ce qui est le cas de celles de Free) ça fonctionne également à distance. Et même plus besoin du paquet sur le NAS

Oui: toutes les modifications (ajouts et suppressions) de fichiers faites par des scripts ou en ligne de commande ne sont pas détectées par l'indexeur. Seul les modules/paquets natifs DSM (samba/ftp/webdav/... serveur, et autres filestation, cloud-bidule, etc etc ..., gèrent ce genre cette situation). Il faut donc utiliser la commande "synoindex" (/usr/syno/bin/synoindex) pour activer un rescan, total ou partiel. Son aide intégrée: Usage: synoindex [OPTIONS] Index Options: -h, --help this help text -A dirpath add a dir -a filepath add a file -D dirpath delete a dir -d filepath delete a file -N new_dirpath old_dirpath rename a dir -n new_filepath old_filepath rename a file -R [all|media|photo|music|video|thumb|dirpath] all: reindex all dirpath that registered in each package media: reindex dirpath that registered in MediaIndex package photo: reindex photo dirpath music: reindex music dirpath video: reindex video dirpath thumb: check converted video of each video file dirpath: reindex this specific dirpath -R user:{user_name} reindex personal photo dirpath -R share:{share_name} reindex share dirpath -R [type_music|type_video|type_photo] reindex dirpath that registered with specific type in MediaIndex Package Index Options: -P [MediaIndex|{package_name}] {index_option} index operation only apply on this package -p [MediaIndex|{package_name}] {index_option} index operation apply all packages except for this package File Index Options: -f {index_option} index operation apply on file index -U photo update photo images Dans le cas présent je pense qu'in "synoindex -R /chemin/du/dossier/modifié" devrait faire l'affaire NB: la commande rend la main immédiatement, c'est normal, ça envoie juste un message à gestionnaire d'indexation qui fait le boulot en tache de fond.

J'ai ce problème depuis des lustres. Je ne suis pas sur que le support Synology veuille traiter ce problème alors j'aimerais avoir votre avis Une tache programmée avec utilisateur *non root* se retrouve avec l'environnement suivant: MAILTO= SHELL=/bin/sh USER=root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin _=/bin/env PWD=/root HOME=/root SHLVL=2 LOGNAME=root Les valeurs de "USER", "LOGNAME" et "HOME" sont incorrectes. Bien entendu il est possible de forcer les bonnes valeurs en début de tache mais je suis étonné qu'une telle anomalie n'ait toujours pas été corrigée depuis le temps.

Je constate dans les logs des tentatives de connections échouées sur le VPN. Exemple: 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: responding to Main Mode from unknown peer 216.218.206.66 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: OAKLEY_CAST_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: no acceptable Oakley Transform 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: sending notification NO_PROPOSAL_CHOSEN to 216.218.206.66:14025 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66 #30: deleting state #30 (STATE_MAIN_R0) 2019-01-28T04:07:59+01:00 fserv pluto[12831]: "L2TP-PSK-NAT"[26] 216.218.206.66: deleting connection "L2TP-PSK-NAT" [whackfd=4294967295] instance with peer 216.21 8.206.66 {isakmp=#0/ipsec=#0} Pourtant ça ne provoque pas de blocage d'IP. Aurais-je oublié une option?

Suffit de s'assurer qu'elle peut faire tourner une application comme VLC par exemple, le paquet embarque ses propres codecs https://play.google.com/store/apps/details?id=org.videolan.vlc "All formats are supported, including MKV, MP4, AVI, MOV, Ogg, FLAC, TS, M2TS, Wv and AAC. All codecs are included with no separate downloads. It supports subtitles, Teletext and Closed Captions." A partir du moment ou c'est un appareil Android ca ne devrait pas poser de problème.

Ceci est juste un lien vers un article comparant les différentes versions de Chromecast. En aucune façon ca ne peut démontrer que la doc présentée dans ta video est une doc officielle Chromecast. La preuve que ca ne peut pas être le cas est que cette dernière ne gère pas Miracast (et encore moins Airplay !!) contrairement à ce qui est visible à l'offset 0:14 Mais il n'installe pas les codecs sur la Chromecast (ce qui reviendrai à en modifier le firmware), il utilise ceux du téléphone (ou d'autres ajoutés par l'appli elle meme). C'est ce qui lui permet de transcoder à la volée. C'est d'ailleurs clairement expliqué dans l'aide intégrée à BubbleUPNP (section "transcodage Chromecast") Suffit de faire le test que j'ai détaillé pour se rendre compte que dès que le téléphone n'est plus disponible le flux est interrompu dans le cas de vidéos non compatibles (pas la peine de mettre hors tension le téléphone, suffit de le basculer en mode avion). Ce test est trivial à faire, je l'ai refait ce matin avant de poster pour m'assurer de ne pas dire de bêtises. Je l'ai reproduit à plusieurs reprise avec deux sources sur mon NAS (une compatible et l'autre non) ,et c'est systématique et reproductible à volonté. NB: Pour vérifier si une video est compatible Chromecast il suffit d'essayer de la caster via DS Video, dans le cas de video non compatible on se retrouve avec cette erreur: Et la même video castée via Bubble sera transcodée à la volée. Ca ne dépend pas du container (que ce soit mkv, avi, mp4 ou autre) mais de *l'encodage* utilisé pour les flux audio et video inclus. Et c'est pas la Chromecast qu'on doit éteindre pour valider le test mais le téléphone, bien entendu (mais j'imagine que c'est une faute d'inattention)

Un deal sur la Box Xiaomi qui tombe à point: https://www.dealabs.com/bons-plans/box-tv-xiaomi-mi-3-international-entrepot-france-5eur-en-superpoints-4199eur-avec-le-code-soldes849-1454201

La doc montrée dans cette vidée n'est pas la doc de la Chromecast officielle mais celle d'un dongle qui implémente la fonction Chromecast (et Miracast au passage). Probablement un truc dans le genre de ceci ou cela