|
39346 | 17/04/2024 | Autre | VM | Freebox V9 (Ultra) | Fermée | Bande passante allouée à VM ? |
Description de la tâche
Bonjour,
En transition Delta→Ultra, j’ai reconstruit from scratch une VM pour les services pihole(lan), vpn (OpenVPN), sshd et proxy web.
Je conduis quelques tests de bande passante en speedtest (à l’extérieur) et le maximum que j’atteins en test UP est ~150 Mbps lorsque connecté en VPN. Contre ~300 Mbps sans VPN.
Du coup je me pose la question de la bande passante I/O allouée aux VM internes à la freebox Ultra. De mémoire, il y avait un bridage sur la Delta, qu’en est-il pour l’Ultra ?
Je sais qu’il y a de nombreux paramètres qui entrent en compte dans ce genre de test : un test d’upload en VPN est limité par la vitesse d’envoi du réseau hôte du terminal duquel le VPN “download/reçoit” le flux de l’App speedtest avant de l’envoyer au serveur de test sélectionné. Et inversement.
Merci.
|
|
36834 | 14/07/2022 | Anomalie | Serveur VPN | Freebox Server V7 (Delta) | Fermée | vpn freebox et dhcp tiers ? |
Description de la tâche
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.
|
|
34604 | 20/04/2021 | Anomalie | Interface Web | Freebox Server V7 (Delta) | Nouveau | 4.3.0 - régression info et gestion disques internes |
Description de la tâche
Bonjour,
Suite mise à jour 4.3.0
- Températures disques 0 °C
> Etat de la freebox
> Paramètres / Disques
- Perte du bouton de vérification disque + - Pertes d'informations sur disques (compteurs, etc.)
> Paramètres / Disques
Cordialement.
|
|
34303 | 16/03/2021 | Anomalie | VM | Freebox Server V7 (Delta) | Fermée | VM non relancée lorsque reboot forcé |
Description de la tâche
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
|
|
34269 | 11/03/2021 | Anomalie | WAN | Tous | Fermée | bug + pb méthode : migration full-stack vers ip partagé ... |
Description de la tâche
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.
|
|
32736 | 10/10/2020 | Évolution | Webcam | Freebox Server V7 (Delta) | Fermée | led nocturne - webcam s'éblouit : surveillance impossib ... |
Description de la tâche
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
|
|
32720 | 09/10/2020 | Anomalie | Webcam | Freebox Server V7 (Delta) | Fermée | Pré-conf bail DHCP non respectée |
Description de la tâche
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.
|
|
30184 | 09/03/2020 | Évolution | LAN | Freebox Server V7 (Delta) | Fermée | contexte pihole : restreindre interrogation DNS externe ... |
Description de la tâche
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,
|
|
30120 | 01/03/2020 | Anomalie | Matériel | Freebox Server V7 (Delta) | Fermée | reboot suite maj 4.1.6 - conf "au pif" |
Description de la tâche
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.
|
|
30078 | 26/02/2020 | Anomalie | LAN | Freebox Server V7 (Delta) | Fermée | Perte conf suite dslam down (étape 2) |
Description de la tâche
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
|
|
29862 | 31/01/2020 | Anomalie | Agrégation 4G | Freebox Server V7 (Delta) | Fermée | 4G activée : dysfonctionnement xDSL |
Description de la tâche
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.
|
|
29846 | 29/01/2020 | Évolution | Interface Web | Freebox Server V7 (Delta) | Nouveau | Gestion des enregistrements - incohérence |
Description de la tâche
Bonjour,
Un enregistrement “en cours” figurant (à juste titre) dans l’onglet “Enregistrements programmés” est cependant également affiché dans l’onglet “Enregistrements terminés” alors que ça n’est pas le cas.
Sa progression (dans le premier onglet) est de 50%, il ne s’agit donc pas d’un enregistrement qui viendrait de se finir et pour lequel l’interface n’aurait pas encore mis à jour le status.
|
|
29657 | 09/01/2020 | Évolution | Matériel | Tous | Fermée | firmware update : changer l'ordre des étapes |
Description de la tâche
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
|
|
28869 | 03/11/2019 | Anomalie | SMB | Freebox Server V7 (Delta) | Fermée | Transfert vers Freebox anémique __si__ "accès authentif ... |
Description de la tâche
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.
|
|
28564 | 10/10/2019 | Évolution | VM | Freebox Server V7 (Delta) | Fermée | Stockage clé(s) ssh |
Description de la tâche
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
|
|
28563 | 10/10/2019 | Évolution | VM | Freebox Server V7 (Delta) | Fermée | Pré-conf bail DHCP pour VM |
Description de la tâche
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
|