Tous les projets

Bonjour,

Il y a longtemps, j'utilisais sans difficulté la fonctionnalité serveur VPN (OpenVPN) de la Freebox avec mes appareils.
Du fait du faible débit up de mon adsl, ce besoin s'est éteint et j'ai viré tout le bazard (conf server fbx, conf clients ,…)

J'utilise encore aujourd'hui sans souci de l'OpenVPN maison (sur un VPS) pour des besoins annexes.

La fibre devant arriver "à l'automne" (au lieu de juin 2021, merci), j'anticipe la remise en service du serveur VPN de la Freebox pour l'accès à certains services internes plutôt que de jouer avec du NAT et de l'https en reverse proxy.

Mes tentatives se soldent toutes par un échec de connexion (ça négocie, ça auth, ça se voit et se cumule brièvement dans les connexions actives) quel que soit le type de VPN testé (ipsec, openvpn B/R, wireguard).

La différence principale par rapport à "avant" est que le DHCP de la Freebox est désactivé au profit du DHCP intégré à mon piHole.
Je subodore que la fonction VPN de la Freebox a besoin du DHCP intégré mais je n'ai aucun moyen de confirmer cela étant donné qu'il n'y a pas d'accès aux logs VPN coté serveur (j'ai vu une tâche à ce sujet, partie aux oubliettes).

Quelqu'un peut-il con/inf-infirmer cette supposition ?

J'aurais bien intégré un OpenVPN sur une VM existante mais le support est limité voire inexistant, de ce que j'ai pu voir, en Debian 11/arm… et toutes les ressources cpu sont déjà mobilisées donc pas d'option de taper une ubuntu server en dmz.

Merci.

Lorsque mon IP a été passée en IP partagée, ma box a été redémarrée durant la nuit.

Au reboot, les VM n’ont pas été relancées avec pour conséquences une perte totale de mon infra LAN puisque je ne repose pas sur le DHCP de la freebox mais sur celui d’une VM (pihole)

⇒ Quand vous rebootez une box de client, vous pourriez envoyer l’instruction proprement histoire que les VM redémarrent avec ?

Merci

Bonjour,

Je suis passablement énervé et je vais essayer de rester objectif et courtois.

Mon matériel :

- Freebox Delta
→ 2 vm hébergées sur la delta (une “frontale ssh/web” et une pihole)

Situation réseau/dns depuis la nuit des temps jusqu’à... cette nuit :

- ipv4 full-stack inchangée depuis des années
→ reverse dns configuré sur cette ip via interface abonné.
- un /64 ipv6 inchangé lui aussi.
→ des records (A, AAAA) chez Gandi qui tapent sur l’ipv4 publique et l’ipv6 “::1”
- une des vm qui fait pihole (dhcp, dns)
- la freebox qui reste évidemment en gateway

Les ennuis commencent :

Cette nuit, mail de free-reseau (lu le matin, hein) qui indique un down du dslam C2S31.
Le mail de “reprise” du dslam n’est jamais arrivé et... lorsque je cherche l’avarie sur le site : aucune trace.
Soit.

Télé-travail, j’allume le portable : WiFi accroche mais pas de bail ipv4.
Qu’à cela ne tienne, j’allume la tour (en eth), pas de bail ipv4.

Passage en conf ip en dur, ouverture d’un navigateur sur l’ip de la box : mes deux vm son éteintes (what ?!)
Je rallume les vm, elles démarrent sans souci... alors pourquoi étaient-elles down ?

Je “navigue à vue” dans freeboxOS pour tenter de trouver une indication :
- courbes xDSL ? En effet, ça a coupé un peu après 4h
→ tiens, c’est “rigolo”, j’ai plus de débit brut et moins d’atténuation !
- Etat internet ? PAF !
→ c’est pas mes IP ça !
→ Et... ho putain, c’est plus en full-stack !

Conclusion :
1) Ca n’a pas “coupé”, la box a carrément été redémarrée. Sans quoi les vm ne seraient pas éteintes.
2) On se permet de bazarder la conf d’un client sans même prévenir quelques jours avant.

Réflexions en guise d’espoir pour les futurs abonnés concernés :

- Dès lors que vous avez un abonné qui a un reverse configuré dans sa console client, vous pourriez pas traiter l’information dans vos moulinettes de “migration” et passer à l’IP suivante pour cause de cas particulier ?
- Quand vous rebootez une box de client, vous pourriez envoyer l’instruction proprement histoire que les VM redémarrent avec ?
- Lorsqu’on va sur l’interface client pour “demander une ip full-stack”, un avertissement informe qu’à moins d’héberger des choses chez soi cette configuration n’est pas utile (je simplifie) → Alors pourquoi diable migrer des IP de client DELTA avec VM actives + reverse dns établi ?? Ca ne fait pas assez de critères pour au moins taper l’IP concernée de côté ?
- Proposez une option pour revenir aux (ipv4 et 6) IP précédentes avec ipv4 full-stack : ça éviterait d’avoir à se coltiner les TTL dns.
→ D’ailleurs pourquoi donc changer le /64 ipv6 qui n’a rien avoir avec la choucroute ? Manquerait plus qu’un routeur ait en charge un subnet ipv6 pour finir en apothéose.

Pour de nombreux points, vous allez me répondre qu’il y a le 3244.
Merci de ne pas les employer pour occulter ce qui pourrait être améliorer techniquement.

Bonsoir,

La caméra du pack de sécurité enclenche automatiquement le mode nocturne et allume une led pour créer une source de lumière.

Problème, ma caméra surveille mon entrée côté jardin tout en étant à l’intérieur derrière une vitre.
Lorsque la led s’allume alors que la nuit tombe, elle filme son propre reflet et il n’y a donc plus de surveillance possible ni de détection de mouvement.

La caméra n’étant pas conçue pour fonctionner à l’extérieur, il paraît essentiel de pouvoir désactiver cette led.

Une demande a été saisie (et fermée) sur ce dev.freebox.fr en janvier 2019 en recevant pour réponse que la fonctionnalité allait arriver “dans quelques semaines”.
So... où est-elle ?

Merci

Bonjour,

Ce jour, réception de la caméra free.

Je note avec satisfaction que son adresse mac est indiquée sur la coque.
Je lui attribue donc une réservation DHCP hors de la plage servie aux clients de passage.

J’initialise ensuite la caméra.
Surprise : elle s’est pris une IP dans la plage dynamique.
Une extinction et un rallumage de la camera ne semble pas déclencher de release/renew.

Contexte :
Freebox Delta
Pas de module de sécurité.
VM Delta pihole
dns et dhcp assurés par le pihole

Seule solution :
- éteindre la cam
- dégager le lease en cours dans la conf du pihole et relancer le service
- rallumer la camera : cette fois elle prend la bonne IP

Conclusion :
- Le DHCP fonctionne correctement (je l’aurais vu assez tôt étant donné la quantité de devices @home)
- Une conception interne à la caméra ou à l’application Freebox d’initialisation empêche le respect d’un bail préconfiguré pour ce matériel.

Sévérité : très basse.
Pourquoi : perso j’ai ma solution ; ça la fout par contre assez mal pour Free qui s’adresse aux geek qu’un truc aussi simple ne fonctionne pas “out of the box” (à quoi bon coller l’adresse mac dans ce cas ?)

Voilà, merci éventuellement pour la suite si j’en prends une seconde et à toute fin utile pour vos usagers.

Bonjour,

J’ai mis en place un pihole sur une vm hébergée par le Delta server ; ça roule sans souci, le filtrage joue son rôle.

Je souhaite proposer une évolution : permettre de déterminer quel(s) hôte(s) du LAN a(ont) le droit d’interroger les DNS autres que celui du pihole.

Dans la configuration actuelle, rien n’empêche la configuration manuelle d’un device du lan permettant d’attaquer en direct un dns public (voire simplement la passerelle) et de bypasser le pihole.

Merci,

Bonjour,

Reboot ce soir pour application de la 4.1.6 suite à impossibilité de rester connecté sur un jeu.

La procédure a duré de 22h33 à 22h47
Sempiternelle alternance étape2 / étape 3 jusqu’à ce que “ça accroche” (mauvaise idée de redémarrer en période faible qualité de service)

A la reprise de service :

- Perte de la conf des baux fixes
- Perte de la conf des redirections de ports
- Wifi en WPA+PSK
- DECT : mode eco (pas éco+) à nouveau décoché.

Conf exclusivement sur freeboxos (pas d’alimentation sur portail free)

Bon courage.

Bonjour,

/contexte
Le dslam c2s31-2 a été hors dispo un peu plus d’une heure et demi ce 26 février, de 18h à 19h30.

La remise en service a été poussive : passages successifs de l’étape 2 à 3 pour finalement arriver à une box up mais pas à l’heure (2h en retard).

Un fonctionnement normal n’a été récupéré qu’à 20h00. Avant cela, l’appli mobile Freebox était incapable de se reconnecter (erreur sur le port), même après redémarrageS et extinction du server
/contexte

Passé 20h, donc, l’accès au web était stable.

Cependant, constat des points suivants :

- Association (config réseau) perdue entre le player et le server
- Disparition des redirections de ports définies précédemment via freeboxos
- Perte des baux dhcp statiques définis précédemment via freeboxos
- Présence de baux statiques a priori récupérés de la conf sur le portail free (supprimés, à présent)
- Agrégation 4G réactivée alors que je la désactive volontairement du fait de son inutilité.

J’ai redémarré encore une fois (22h35) le serveur par acquis de conscience : peine perdue.
J’ai donc rentré à nouveau mes configurations dhcp static et redirections.

A cette occasion :

- La liste déroulante “ip destination”, dans le formulaire de redirection de ports, montre que la conf basique du serveur dhcp n’a pas été respectée durant le dysfonctionnement : présence d’ip attribuées hors plage configurée (non, elle n’a pas pu saturer : 40 slots).

Je pense n’avoir rien oublié.

Lat

Bonjour,

Je ferai dans l’euphémisme en disant simplement que je “commence” à être sérieusement à bout de patience concernant le comportement de la Delta.

Je récapitule le comportement constaté aujourd’hui avant et après mise à jour en 4.1.5 :

→ Débit internet lent ; navigation poussive ; récupérer un ficher de 6Mo prend une éternité
→ L’application “screensaver” du freestore saccade genre 1fps

Le débit temps réel affiche quelques Kb/s dans freeboxOS
La 4G sommeille.

→ Je décoche “Activer la 4G”, j’applique
→ Je passe à la “vue” suivante dans screensaver : le débit xDSL download sature ma synchro de ligne et l’image est fluide sans saccade.
→ Une mise à jour d’appli dans le store androïd se fait enfin à vitesse convenable

Je reviens à l’état précédent :

→ Réactivation de la 4G, appliquer
→ Vue suivante dans screensaver : 1fps

Je reviens “sans 4G” → à nouveau un débit correct.

Je mets à jour en 4.1.5 : pas d’amélioration.

Je suis donc actuellement “sans 4G” et force est de constater que l’usage du web (pourtant navigation simple) est redevenu agréable, il n’y a pas cette latence qui finit par faire soupirer et balancer le portable sur le côté pour faire autre chose.

Entre les trucs qui n’arrivent pas pour le player (support formats, atmos, …) et maintenant ça, je me demande si on n’est pas dans le défaut commercial caractérisé.
Je dis ça sans cynisme, c’est réellement préoccupant.

sur https://dev.freebox.fr/blog/?p=10144, la date de relase indique 20 novembre.

par ailleurs, sur le formulaire présentement utilisé pour soumettre cette “tâche”, la liste de versions s’arrête à 1.0.9

Bonjour,

Serait-il possible d’inscrire dans vos projets d’évolution le fait que les box téléchargent à l’avance les update de firmware des servers ET des players avant de devoir redémarrer ?

Rebooter et devoir attendre que les binaires se téléchargent… Pour imposer un nouveau redémarrage après l’update effective, c’est franchement lourd à force et d’autant plus quand la qualité de la connexion n’est pas au rendez-vous.

Cela accélèrerait le processus et vous pourriez même imaginer une invite à l’écran télé : une mise à jour a été téléchargée pour votre <server|player> etc.

Merci

Bonjour,

Contexte :

Client win10pro 1903
Server Delta 4.1.1 - 3h d’uptime
Disque source Toshiba P300
Transfert LAN (lien Gigabit)
Disque cible1 : array 3x1To RAID0 disques HGST 7K1000-1000 - logements 2,3,4 (volume “perso”)
Disque cible2 : ssd 512Go - logement 1 (disque “fonctionnement box”)
Share windows activé avec authentification (login “freebox” par défaut + mdp ponctuel)
VM arrêtée en cours de transfert, sans effet.

Share 1 et 2 montés via net use

ServerName ShareName UserName     Credential     Dialect NumOpens
---------- --------- --------     ----------     ------- --------
fbxsrv     3To       saloon\abc fbxsrv\freebox 1.5     1
fbxsrv     ssd512    saloon\abc fbxsrv\freebox 1.5     1

Constat :

Lancement du transfert source vers cible1 via robocopy (source cible /MIR /R:0 /W:0 /NP)
⇒ Qu’importe la taille et le type du fichier (jpeg ~4Mo, raw ~25Mo, mp4 ~500Mo), le transfert occile de 0 (!) à 100Mbit/s (task manager) avec parfois une pointe à 500.
Le transfert peut très bien s’interrompre en plein milieu d’un fichier pour reprendre ensuite comme si de rien n’était.
Au bout de 2h de copie ⇒ ~55Go transférés.

Avant que je n’interrompe le massacre, j’ai lancé un test de copie (copy/paste windows) d’un iso win10 vers le ssd (cible2). Même combat : plafond à 10Mo/s, instable.
La source n’était pas la même (ssd système du pc, sata III)

⇒ J’arrête le transfert
⇒ Je tue les montages
⇒ Je supprime l’authentification dans FreeboxOS
⇒ Je recrée les montages et relance mon robocopy

Passé les fichiers déjà copiés (obv), stabilisation du transfert à ~600Mbit/s (et saturation si fichier volumineux)
Si copie de l’iso en // vers cible2, saturation du lien LAN

30 minutes plus tard, je suis à 140Go (de plus) d’envoyés.

Problème (de fond) : j’aimerais pouvoir protéger les share tout en conservant des performances honorables.

Cadeau Bonux en passant : si nous pouvions voir un jour une différenciation d’accès (lecture seule, accès complet) sur les partages, ce serait top (genre “pas d’auth, on est en lecture”).

Merci.

Bonjour,

A l’instar de ce que permet par exemple la console online (dedibox), permettre de stocker des clés ssh dans freeboxos pour réutilisation par l’assistant de création de VM serait intéressant.

Merci

Bonjour,

Dans le processus de création d’une VM, il serait intéressant de permettre la préconfiguration du bail DHCP afin de placer directement la VM dans le bon pool.

J’illustre :
Sur ma conf freebox, j’ai une plage DHCP très courte pour les postes qui se connectent ponctuellement (wifi, etc.) et tous mes appareils “résidents” sont eux configurés en bail statique en dehors de cette plage.

Une VM ne doit pas avoir une ip aléatoire dans un pool dynamique, il serait donc intéressant de soit permettre de définir à l’avance l’adresse mac de la future VM et donc de pouvoir attribuer un bail static avant de l’initialiser soit de pouvoir créer cette réservation directement dans l’assistant de création de la VM.

Merci

Bonjour,

Hier, décidant de créer un nouveau (et 1er, en fait) bouquet. J’ai tenté par différentes façons de pouvoir le nommer :

- en étant sur l’une des chaînes à inscrire ⇒ ok ⇒ bouquet perso ⇒ ajouter à un nouveau bouquet
- via le menu télévision de l’accueil, bouquets personnalisés ⇒ créer un nouveau bouqet

Problème :
⇒ Le champ de saisie du nom est proposé mais le clavier virtuel n’est pas affiché.
⇒ Appuyer sur ok valide le caractère “G” dans le champ de nommage : le clavier fonctionne donc mais est invisible.
⇒ Utiliser les touches directionnelles et appuyer sur ok provoque bien la saisie d’un autre caractère.

Reboot du player : clavier à nouveau visible.

Note au passage : la façon d’ajouter un bouquet existant aux favoris n’est vraiment pas intuitive !

Différentes situations :

- matin : ok alexa, flash quotidien ⇒ parfois ça allume l’ampli et la télé via CEC pour bloquer sur une appli de lecture minimaliste au lieu de simplement restituer le flash quotidien via les HP du playeur sans allumer toute la chaîne.
⇒ reboot électrique obligatoire

- soir, retour boulot : ok freebox, allume la télé ⇒ le playeur s’allume, l’ampli suit... la télé aussi mais n’affiche rien.
⇒ reboot électrique obligatoire

- soir, retour boulot : télé allumée sans signal.

- n’importe quand : ok freebox ou ok alexa ⇒ son tronqué indiquant une soit disant “écoute” mais plus aucune commande ne passe.
⇒ reboot électrique.

Résultat, quand je m’absente quelques jours, je débranche serveur et playeur électriquement... et par conséquent aucune fonctionnalité distante possible.

Un comble de ne pas pouvoir avoir confiance dans un équipement de 2019 sur ces aspects basiques.