Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour,
Depuis le 1er septembre 2026, la freebox ne répond plus au ping 8.8.8.8. C'est juste l'ICMP, "nc -zv 8.8.8.8 53" répond bien.
En temps normal, ça ne m'aurait pas dérangé plus que ça sauf que j'ai une alarme Somfy qui utilise le ping 8.8.8.8 pour vérifier la connexion internet.
Donc mon alarme n'est plus connecté à internet ce qui est quand même très embêtant.
Je ne suis pas un cas isolé, il y a plusieurs posts sur le sujet chez somfy dont le support soit dit en passant est 0:
https://forum.somfy.fr/questions/3757875-perte-subite-connexion-wifi-link-essential?new_answer=1 https://forum.somfy.fr/questions/3757915-link-advanced-aucune-connexion-internet https://forum.somfy.fr/questions/3757895-urgent-link-advanced-deconnecte-wifi#answer_9484633

Pour info j'ai la dernière 4.12.4 (non listé dans le champs "Basée sur la version")
Help please :)

Bonjour l’équipe Freebox,
Depuis l’intégration très appréciée de la résolution DNS locale, le suffixe attribué automatiquement aux baux DHCP est codé en dur sur .home.
Bien que fonctionnelle, cette approche pose un problème de conformité avec les standards actuels : le TLD .home n’est pas officiellement réservé et expose à des risques (bien que faibles) de collision TLD.
L’IETF a publié en 2018 la RFC 8375 (Special-Use Domain ‘home.arpa.’), qui définit très clairement home.arpa comme le standard exclusif et sécurisé pour les réseaux locaux résidentiels.
Actuellement, l’interface Freebox OS ne permet ni de modifier ce comportement, ni d’éditer l’Option DHCP 15 (Domain Name) pour diffuser un autre suffixe aux appareils du réseau (indispensable pour les utilisateurs gérant un homelab, des certificats SSL locaux ou des services conteneurisés).
Comportements attendus / Solutions proposées :
Ajouter un champ texte “Nom de domaine local” dans les paramètres DHCP de Freebox OS (Mode Avancé), permettant aux utilisateurs de modifier l’Option 15.
Idéalement : Remplacer la valeur par défaut .home par home.arpa sur les nouvelles configurations pour se conformer nativement à la RFC 8375.
Lien de référence :
https://www.rfc-editor.org/info/rfc8375/ Merci d’avance pour votre considération et pour le travail sur Freebox OS !

Bonjour,

Je rencontre un problème reproductible d’association Wi-Fi avec une Google Nest Cam intérieure filaire de 3e génération.

Configuration :

1. Freebox Ultra V9
2. Freebox OS 4.12.2
3. Réseau utilisant initialement une configuration commune pour les bandes 2,4 GHz, 5 GHz et 6 GHz
4. Google Nest Cam intérieure filaire, 3e génération
5. Configuration réalisée depuis l’application Google Home
6. Tests effectués avec un iPhone récent sous iOS bêta et avec un autre iPhone sous une version stable d’iOS

Symptômes :

La Nest Cam est détectée par Google Home et commence son appairage. Elle passe en mode association, puis la configuration échoue de manière intermittente avec différents messages :

1. « Impossible de trouver l’appareil »
2. « Impossible de se connecter au Wi-Fi »
3. « Un problème est survenu »

Dans certains cas, la caméra apparaît brièvement comme connectée dans Freebox OS avec un excellent niveau de signal, mais Google Home indique malgré tout que la connexion Wi-Fi a échoué.

La caméra avait initialement réussi à être ajoutée, mais passait ensuite hors ligne. Après sa suppression de Google Home, il est devenu extrêmement difficile de terminer un nouvel appairage.

Une première caméra présentait déjà un comportement similaire. Elle a été remplacée par Google, mais la caméra de remplacement a rencontré pratiquement les mêmes problèmes.

Observations techniques :

Des captures radio ont été réalisées pendant les tentatives d’association.

La caméra parvient à :

1. détecter le SSID ;
2. effectuer l’authentification 802.11 ;
3. s’associer à un BSSID de la Freebox.

Certaines tentatives se bloquent ensuite pendant le « 4-Way Handshake » WPA2/EAPOL.

Des retransmissions EAPOL sont observées, suivies d’un timeout et parfois d’une déconnexion avec le code de raison 15.

Dans ces situations, la caméra n’atteint pas systématiquement l’étape DHCP. Le problème intervient donc avant le DNS et avant la connexion aux services cloud Google.

Lors des tests avec un SSID dédié en 2,4 GHz, plusieurs BSSID correspondant au même réseau ont été observés. La caméra a essayé successivement plusieurs BSSID.

Certaines tentatives ont échoué pendant le handshake EAPOL. Une tentative a finalement réussi sur l’un des BSSID : les quatre messages EAPOL ont alors été échangés correctement, puis la caméra a obtenu une adresse IP et poursuivi sa

configuration.

Le comportement semble donc intermittent et peut varier selon le BSSID ou la carte Wi-Fi de la Freebox sélectionnée par la caméra.

Tests effectués sur la Freebox :

1. configuration Wi-Fi commune ;
2. séparation temporaire des bandes ;
3. réseau exclusivement 2,4 GHz ;
4. création d’un SSID dédié ;
5. création d’un réseau invité ;
6. désactivation temporaire des radios 5 GHz et 6 GHz ;
7. désactivation du Wi-Fi steering ;
8. désactivation du MLO ;
9. largeur de bande limitée à 20 MHz ;
10. canal 6 fixe ;
11. canal automatique ;
12. essais après sélection automatique du canal 1 ;
13. WPA2 uniquement ;
14. mode de compatibilité WPA2/WPA3 ;
15. PMF désactivé ;
16. GCMP-256 désactivé ;
17. SSID visible ;
18. WPS désactivé ;
19. EAPOL version 2 ;
20. 802.11n activé ;
21. essais avec 802.11ax et 802.11be désactivés ;
22. redémarrage de la Freebox ;
23. réinitialisation complète de la caméra ;
24. suppression et nouvel ajout de la caméra dans Google Home ;
25. retour final à la configuration Wi-Fi commune.

Tests DNS et Internet :

Afin d’écarter un problème de filtrage, les essais suivants ont également été réalisés :

1. contournement complet d’AdGuard ;
2. DNS de la Freebox ;
3. DNS Cloudflare ;
4. DNS Google ;
5. absence de filtrage DNS personnalisé ;
6. vérification du DHCP et de l’accès à Internet avec d’autres appareils.

Le résultat ne dépend pas du serveur DNS utilisé.

Les autres équipements accèdent correctement à Internet. De plus, les échecs observés interviennent régulièrement avant même l’attribution d’une adresse DHCP.

Test comparatif sur un point d’accès indépendant :

Pour isoler la Freebox, un point d’accès de diagnostic a été créé sous Linux avec un adaptateur Alfa Network AWUS036AXML utilisant une puce MediaTek MT7921AUN.

Configuration du point d’accès :

1. SSID distinct ;
2. 2,4 GHz uniquement ;
3. WPA2-PSK ;
4. chiffrement CCMP/AES ;
5. PMF désactivé ;
6. largeur de bande de 20 MHz ;
7. canal 6 ;
8. DHCP et NAT indépendants ;
9. capture complète du trafic réseau.

Sur ce point d’accès indépendant, la même Nest Cam et le même iPhone ont réussi l’appairage.

La caméra a ensuite :

1. terminé le handshake WPA2 ;
2. obtenu une adresse DHCP ;
3. effectué ses requêtes DNS ;
4. contacté les services Google ;
5. téléchargé une mise à jour OTA de 112 075 145 octets ;
6. redémarré ;
7. rejoint automatiquement le réseau ;
8. affiché correctement le flux vidéo en direct dans Google Home.

Ce test permet d’écarter raisonnablement :

1. une panne matérielle permanente de la caméra ;
2. un problème général avec Google Home ;
3. le téléphone utilisé ;
4. la version bêta d’iOS ;
5. AdGuard ;
6. le serveur DNS ;
7. l’accès Internet ;
8. le compte Google.

Résultat actuel :

La caméra a fini par fonctionner après de nombreuses tentatives et après sa mise à jour, mais la réussite de l’association n’a pas été constante.

Le problème ne semble pas être une simple faiblesse du signal : la caméra a été testée à proximité de la Freebox et un signal très fort a été observé.

Les résultats orientent plutôt vers :

1. une instabilité du handshake WPA2/EAPOL ;
2. une différence de comportement entre les BSSID ou cartes Wi-Fi de la Freebox ;
3. une interaction avec la configuration commune multi-bande ;
4. le Wi-Fi steering ;
5. le mode WPA2/WPA3 de transition ;
6. PMF, MLO, 802.11ax ou 802.11be ;
7. ou un problème dans le firmware Wi-Fi de la Freebox Ultra.

Captures disponibles :

Je dispose de plusieurs captures PCAP correspondant :

1. à un appairage réussi sur le point d’accès indépendant ;
2. à des échecs d’appairage sur la Freebox ;
3. à une tentative réussie après plusieurs échecs ;
4. aux échanges EAPOL, DHCP, DNS et OTA.

Je préfère ne pas publier ces captures directement sur le bugtracker, car elles contiennent des identifiants réseau. Je peux néanmoins fournir une version anonymisée ou les transmettre par un canal privé à l’équipe Freebox.

Questions pour l’équipe technique :

1. Pouvez-vous examiner les journaux Wi-Fi internes de la Freebox pendant une nouvelle tentative d’association ?
2. Pouvez-vous vérifier la cause exacte des timeouts EAPOL et des déconnexions avec le code de raison 15 ?
3. Existe-t-il un problème connu avec les Nest Cam récentes sur la Freebox Ultra ?
4. Existe-t-il une différence de firmware ou de comportement entre les différentes cartes ou les différents BSSID Wi-Fi de la Freebox Ultra ?
5. Le mode WPA2/WPA3, PMF, MLO, le steering ou le fonctionnement multi-BSSID peuvent-ils provoquer ce type d’échec ?
6. Une correction du firmware Wi-Fi ou de Freebox OS est-elle prévue ?
7. Pouvez-vous indiquer une configuration temporaire officiellement recommandée sans désactiver définitivement les fonctionnalités Wi-Fi récentes ?

Je peux reproduire le problème à une heure précise afin de permettre la corrélation avec les journaux internes de la Freebox.

Merci de transmettre cette tâche à l’équipe chargée du firmware Wi-Fi de la Freebox Ultra.

Bonjour,

Depuis plusieurs semaines, j’ai des problème avec mon galaxy S21 et le wifi 2.4ghz.

En effet, lorsque je suis connecté à cette bande, j’ai un débit qui chute complètement.
Les speed-test, quand ils arrivent à détecter que je suis connecté au wifi, me donne des résultat de 1,XX mbps.

C’est un problème que j’ai remarqué il y a quelques semaines, lorsque le soir dans mon lit, je n’arrivais pas à charger de simples page web.

Il faut que deconnecte reconnecte le wifi pour passer sur la bande 5ghz qui fonctionne bien.
Si je me rapproche de la box, parfois, ça passe sur la 5ghz, parfois non.

J’ai explorer la piste du téléphone fautif, mais malgré toutes mes réinitialisations de paramètre réseau sur le smartphone, rien ne change.

Ma conjointe n’a pas ce problème sur son galaxy s23, parfois lorsque je suis à côté d’elle, je vois qu’elle est bien sur le Wifi5 et moi non.

Je post ici pour savoir si d’autres personne constate ce problème afin de déterminer une bonne fois pour toute si c’est côté Freebox ou smartphone.

merci

Bonjour

En espérant que vous allez bien.
Tout d’abord je vous détaille ma configuration:
- Freebox Revolution (mise à jour avec le dernier firmware hier soir)
- Repeteur WiFi Freebox
- Multiple devices se connectant soit en 2,4GHZ soit en 5GHZ

Hier j’ai du redémarré mon serveur révolution qui du coup s’est mis à jour avec en 4.10.2
Et depuis j’ai un soucis assez impactant.
Tous mes devices qui étaient connectés sur mon WIFI 5GHZ du Server (précision importante) ne fonctionnent plus du tout.
Ils voient le WIFI sans problème mais la box ne leur attribuent pas d’IP (ils en reçoivent une en APIPA)

Ce soucis apparemment ne concerne que les devices connectés au Server directement car j’ai des devices qui sont connectés au répéteurs et eux aucun soucis le répéteur leur attribuent bien une IP et les devices ont bien une connection à Internet sans problème.
Ce soucis est présent que sur la partie 5GHZ et non sur la 2,4GHZ qui elle fonctionne nikel

J’ai fait le test avec mon Iphone pour confirmer cette théorie:
- Quand je le connecte près du serveur en 5GHZ il reçoit une adresse en APIPA et via le répéteur en 5GHZ c’est nikel
- Quand je le connecte près du serveur en 2,4GHZ il se connecte au réseau et reçoit une bonne adresse de ma plage DHCP et peut se connecter au net.

C’est impactant car j’ai par exemple ma centrale d’alarme fournie par ma banque qui ne peut que se connecter en 5GHZ et qui est près du server donc depuis hier elle fonctionne en mode dégradé.

J’air redémarré la box des dizaines de fois en mode normal et une fois en mode secours sans succes.

Petit ajout: j’ai remarqué via Freebox OS que beaucoup de mes devices ont des noms d’hotes, mDns qui ne correspondent plus (par exemple des cameras de sécurités qui ont pris le nom de mon ampli home cinéma)
Et aussi des devices se prennent pour d’autres (j’ai par exemple une camera qui apparait comme une freebox player ou mon téléphone comme une de mes enceintes connectées).

Pouvez vous m’aider car cela est très impactant?

Je suis dispo pour envoi de la mac de ma freebox et des tests si besoin.

Merci d’avance et bonne journée

Bonjour,

Je rencontre depuis juin 2026 une dégradation récurrente du débit WAN de ma Freebox Pop.

Après un redémarrage du Server, le débit descendant revient immédiatement autour de 2,3 à 2,4 Gbit/s sur le port Ethernet 2,5 Gbit/s. Après plusieurs jours de fonctionnement, généralement cinq à six jours, les performances vers Internet diminuent fortement.

Lors du premier constat, le débit plafonnait autour de 680 à 700 Mbit/s. Lors d’autres occurrences, la dégradation était moins importante, autour de 1,5 Gbit/s selon la destination. Un redémarrage de la Freebox rétablit le débit normal, mais le problème finit par revenir.

Le Server est une Freebox v8 (r1), actuellement sous Freebox OS 4.12.4-r1.

Je participe au programme bêta concernant l’accès aux canaux DFS en Wi-Fi avec les répéteurs. Cependant, le problème de débit était déjà présent avant mon inclusion dans ce programme. Il n’a donc pas commencé avec cette version bêta.

Configuration et contrôles effectués :

- PC sous Windows 11 connecté en Ethernet 2,5 Gbit/s ;
- carte réseau Marvell AQtion, lien négocié à 2,5 Gbit/s ;
- débit local mesuré autour de 2,3 à 2,36 Gbit/s pendant que les débits WAN étaient dégradés ;
- liaison FTTH/PON toujours indiquée comme active ;
- profil affiché de 5 Gbit/s descendant et 900 Mbit/s montant ;
- module SFP présent et indiqué comme fonctionnel ;
- puissance optique observée : environ -17,9 dBm en réception et 2,6 dBm en émission ;
- aucune désynchronisation ni reconnexion visible dans l’historique au moment de la dégradation.

Exemple de mesures prises pendant un état dégradé :

- test local : environ 2,36 Gbit/s ;
- téléchargement OVH IPv4 : environ 778 Mbit/s ;
- téléchargement OVH IPv6 : environ 647 Mbit/s ;
- serveur de test Free : environ 1,63 Gbit/s.

Les mesures répétées montrent que les résultats dépendent de la destination et du nombre de connexions. Certains chemins restent très faibles, alors qu’un téléchargement IPv4 utilisant quatre connexions simultanées vers Scaleway peut encore atteindre environ 2,3 Gbit/s.

Il ne semble donc pas s’agir d’un problème avec le PC, la carte réseau, le câble ou le lien Ethernet. Je ne peux pas non plus affirmer qu’il s’agit d’un bridage global de la ligne, d’un problème exclusivement IPv6 ou d’une QoS. Le comportement fait plutôt penser à un état dégradé du datapath, du routage ou de la gestion des connexions dans le Server, état qui est réinitialisé lors de son redémarrage.

Le problème ressemble à plusieurs tâches existantes :

-  FS#32586  : passage d’environ 2,3 Gbit/s à 680-700 Mbit/s après une période de fonctionnement, corrigé par un redémarrage :

https://dev.freebox.fr/bugs/task/32586

- FS#38855 : baisse similaire sur le port 2,5 Gbit/s, temporairement corrigée par une modification d’un réglage IPv6 :

https://dev.freebox.fr/bugs/task/38855

- FS#37995 et FS#40475 : dégradation principalement observée en IPv6 sur une Freebox Pop :

https://dev.freebox.fr/bugs/task/37995
https://dev.freebox.fr/bugs/task/40475

Dans mon cas, les mesures ne permettent pas de confirmer que la cause est uniquement liée à IPv6. Des débits faibles ont été observés en IPv4 comme en IPv6, avec une forte variation selon la destination. Le point reproductible est que les performances se dégradent après plusieurs jours et qu’un redémarrage du Server les rétablit temporairement.

Étapes de reproduction :

1. Redémarrer la Freebox Pop.
2. Vérifier un débit descendant d’environ 2,3 Gbit/s sur le port 2,5 Gbit/s.
3. Laisser le Server fonctionner plusieurs jours.
4. Refaire les mêmes tests vers plusieurs destinations, en IPv4 et en IPv6.
5. Constater la baisse des débits WAN alors que le débit local reste normal.
6. Redémarrer uniquement le Server.
7. Constater le retour immédiat du débit WAN normal.

Résultat attendu :

Le débit WAN doit rester stable sans nécessiter un redémarrage périodique du Server.

Résultat constaté :

Les performances WAN se dégradent après plusieurs jours. Le débit revient immédiatement à son niveau normal après un redémarrage, puis le problème réapparaît.

J’ai d’abord signalé ce comportement à l’assistance Free, avec les mesures disponibles. Il m’a été répondu qu’un débit d’environ 700 Mbit/s était déjà satisfaisant et qu’il n’y avait donc pas de problème à traiter. Malgré le caractère répétable du défaut et le retour immédiat du débit après redémarrage, l’assistance a refusé de transmettre le dossier à une équipe technique.

J’ouvre donc cette tâche afin que le problème puisse être examiné techniquement. Le fait que 700 Mbit/s reste utilisable ne change pas le constat : le débit passe de plus de 2,3 Gbit/s à environ 700 Mbit/s, ou à un niveau intermédiaire selon l’occurrence, puis revient à la normale après un redémarrage.

Je peux fournir l’adresse MAC du Server ainsi que les relevés horodatés si cela permet de retrouver les journaux correspondants côté Free.

Je possède une alarme paradox qui communique avec le “cloud” du fabricant (SWAN) avec les protocoles et ports suivants:
Port Description (used for)
UDP 53 DNS UDP 123 NTP
UDP 5683 COAP (back up)
TCP 8883 MQTT port SWAN
TCP 443 OTA (firmware upgrade + certificate download)
TCP Port 465, 587 Usually for email server, may differ depending on the email server used.

Cette communication ne fonctionne plus, à priori, depuis le passage en 4.12.3

Voici les tests que j’ai réalisé:
Alarme sur LAN freebox: connectivité au cloud KO
Alarme sur routeur 4G: connectivité au cloud OK

Alarme sur LAN freebox + Client (App sur smartphone) en WiFi freebox ⇒ connectivité KO
Alarme sur routeur 4G + Client (App sur smartphone) en WiFi freebox ⇒ connectivité KO
Alarme sur routeur 4G + Client (App sur smartphone) en 4G ⇒ connectivité OK

La freebox semble donc bloquer les flux depuis l’alarme mais aussi ceux depuis le client (App) qui se connecte également au serveur distant du fabricant (pas de flux purement local). A priori, les protocoles utilisés sont MQTT et potentiellement CoAP

Il n’y a eu aucune mise à jour ni changement de config coté alarme, uniquement les mises à jour de la freebox ultra

Je suis passé en full-stack mais aucun changement

Doc sur le module IP de l’alarme: https://www.paradox.com/Downloader/?ID=12391

ça serait bien de pouvoir rajouter des entrées AAAA au DNS. ça permettrais d'utiliser ce nom de domaine pour l'ipv6 ce qui réduirai le besoin d'une full stack ipv4.

Bonjour

Depuis le passage en 4.12.3

La retransmission est forte en IPv4 (un routeur v4 qui sature ? (la box?))

[ ID] Interval           Transfer     Bitrate         Retr
[ 95]   0.00-10.04  sec  4.00 GBytes  3.42 Gbits/sec  13097             sender

nulle en IPv6

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  8.46 GBytes  7.24 Gbits/sec    0            sender
[  5]   0.00-10.00  sec  8.41 GBytes  7.22 Gbits/sec                  receiver

Le prefixe IPv6 /60 routé sur ma freebox a été modifié sans prévenir… Est-ce normal ?

IMPACT de ce changement:
Reconfiguration complète du réseau nécessaire, des machines, des DNS et certificats…

J’espère que c’est un BUG et qu’il y a un rollback possible.

Si ce n’est pas un bug, il serait bien de prévenir à l’avance pour des changements aussi impactant.

[Edit 20260813] : j’ai commencé à mettre à jour l’infra avec le nouveau bloc et je dois racheter des certificats valides pour certaines des IPv6 ⇒ Finalement merci de ne pas rollback

Cordialement
nbanba

Bonjour
Depuis ce matin, plus d’accès extérieur depuis ma Freebox.
sa me dis un probleme est survenu lors de cette requette au serveur (erreur 503)

Impossible de connecter une machine à laver Hisense WD5I1245BWRH en wifi 2.4 ghz que soit sur la freebox ultra directement ou sur le répéteur.
L’isolation du 2.4 ghz ne change rien. D’autres équipements fonctionnent en 2.4 ghz comme un aspirateur Dreame.

Bonjour,

Depuis peu, je constate une perte de débit ainsi qu’une instabilité réseau entre mon PC et ma Freebox Ultra, connectés via le port SFP.

Les symptômes observés sont les suivants :

• Les transferts de fichiers via SMB entre le disque interne de la Freebox et mon PC échouent systématiquement.

• Dans l’interface Freebox OS (Réseau local > Switch), il est impossible de consulter les statistiques du port SFP :

1. Les champs Erreurs en réception et Erreurs en émission affichent -1 octet.

Ces dysfonctionnements n’étaient pas présents auparavant et semblent indiquer un problème matériel ou logiciel lié au port SFP ou à son module.

Pouvez-vous, s’il vous plaît, vérifier de votre côté l’état de la Freebox et m’aider à identifier puis résoudre ce problème ?

Informations :

• Modèle : Freebox Ultra

• Adresse MAC : 38:07:16:C2:6F:6E

Je vous remercie par avance pour votre aide et reste disponible pour tout test ou information complémentaire.

Cordialement,

Bonjour,

Je me suis rendu compte aujourd’hui que la protection par brute force ne fonctionne plus sur l’interface web Freebox OS, auparavant après plusieurs tentative infructueuse un message disait de souvenir " trop de tentative échoué " et il faillait patienter un certain temps pour pouvoir refaire une tentative.
Ce message ne s’affiche plus aujourd’hui apres plus de 50 essais … Et ensuite je peux me connecter immédiatement avec les bon identifiants. Ce qui laisse le champ ouvert au attaque par brute force.

Cordialement.

bonjour
J’ai un dd qui a sauté et je ne peux remettre dans le RAID5 le nouveau disque
cela avait été résolu avec la version 4.1.3 mais on me dit que ma version 4.12 doit le faire et ce n’est pas le cas

Je suis avec une box Delta bien sur
et mes dd sont des SSD
merci

Bonjour,

Je viens de remplacer mon Server V6 Revolution par une Freebox Ultra. Le menu des machines virtuelles n’est pas disponible dans Freebox OS. Après redémarrage complet du Server après avoir ajouté disque NVMe + défini le disque externe sur ce dernier, le problème reste présent.

Informations du Server :

- modèle API : `Freebox v9 (r1)` / `fbxgw9-r1` ;
- firmware : `4.12.3` ;
- version d’API : `16.0` ;
- connexion Internet : état `up` ;
- état des mises à jour : `up_to_date`.

Le stockage ne semble pas être la cause :

- `disk_status: active` ;
- `user_storage_powered: true` ;
- stockage principal : `DisqueFreebox` ;
- SSD NVMe de 1 To détecté, partition ext4 montée, environ 917 Go libres.

Avec une application API autorisée, disposant de la permission `vm: true`, les requêtes en lecture seule renvoient :

GET /api/v16/system/

result.model_info.has_vm : champ absent

GET /api/v8/vm/info/

{"success":false,"error_code":"internal_error","msg":""}

GET /api/v8/vm/

{"success":false,"error_code":"service_down",
 "msg":"Impossible de récupérer l’état de cette VM: Ce service n’est pas disponible actuellement"}

GET /api/v8/vm/distros/

success=true, 9 distributions listées

Les endpoints VM donnent le même résultat sur les versions d’API v7 à v16.
La documentation locale de Freebox OS indique que l’API VM est disponible
pour les box dont `model_info.has_vm` vaut `true`, et que ce champ est en
lecture seule.

Pourriez-vous vérifier si l’absence de `model_info.has_vm` et l’erreur
`service_down` correspondent à une régression ou à un mauvais provisionnement
du service VM dans le firmware 4.12.3, ou bien à une erreur de settings de ma part ?

Merci.

## Références techniques

- Documentation API locale :

https://mafreebox.freebox.fr/doc/index.html#SystemModelInfo.has_vm

- Ticket Freebox montrant `has_vm: true` sur une Ultra `fbxgw9-r1` en firmware

4.8.5 : https://dev.freebox.fr/bugs/task/39132

Bonjour,

L’ajout du next-hop sur le dernier Freebox OS permet maintenant d’utiliser l’IPv6 avec un routeur derrière, c’est parfait merci ! (apparemment que pour la V6, rien d’affiché sur la v5/cristal encore ...)

Pour pouvoir utiliser ces services de façon un peu plus “carrée” il manque juste la délégation des DNS inverses.
Pouvez-vous rajouter (à priori dans l’interface de gestion du compte) la possibilité d’indiquer 2 ou + serveurs DNS inverses ?
(charge à l’utilisateur de comprendre et paramétrer correctement ce service)

A priori il n’y a pas de reverse du tout en IPv6 actuellement, même pas un générique sur *.free.fr/*.proxad.net

Merci par avance !

Bonjour,
Depuis peu, j’accède difficilement à mon système de sécurité Freebox delta avec l’application Freebox Home.
Je viens de me rendre compte que ça coïncide à peu près avec le fait que j’ai créé un nom de domaine en .freeboxos.fr sur freebox OS dans la section paramètre > nom de domaine.
J’ai remarqué dans Freebox home que le nom de domaine de ma freebox ajouté est toujours l’ancien xxxxxxx.fbxos.fr créé automatiquement par défaut.
Je l’ai testé et il fonctionne mais m’affiche une alerte de sécurité concernant le certificat.
Je ne sais pas si c’est cela qui gêne le bon fonctionnement de Freebox home … j’ai essayé de supprimer toutes les données de l’application android et quand je l’ajoute à nouveau, elle refuse d’utiliser le nouveau nom de domaine en .freeboxos.fr
Quelqu’un aurait des informations quant au fait que l’application n’arrive pas à joindre mon système d’alarme régulièrement s’il vous plait ?

bonjour

sur freebox os dans les statistiques trouvables sur “Etat de la freebox” puis “état internet” le débit actif en download du wifi sur bande 5ghz n’est pas décomptabilisé, cela ne semble compter que l’agrégation des ports ethernet ainsi que le wifi 2.4ghz, et l’upload 5ghz.

Idem via l’API, cela affiche la même valeur qui est trouvable sur “état internet”, obligeant a passer par une addition avec le débit RX de chaque Device en wifi 5ghz afin d’avoir le débit réel utilisé à un instant T.

n’est-il pas possible d’avoir les statistiques tout confondu ou directement celles du SFP, ou encore une stat WAN ?

Bonjour,
Je dispose d’un petit LAN commuté par une Freebox Server v8 r1, avec certains équipements actifs en Wifi, d’autres en Ethernet (directement sur les ports Ethernet de la Freebox).
J’ai remarqué de nombreux problèmes sur la commutation locale Ethernet-Wifi (entre un équipement Wifi et un équipement connecté à l’un des ports Ethernet) : débits très faibles (< 500ko/s) pertes de paquets. Ils arrivent quelque soit le protocole applicatif : SMB, FTP/SFTP… Les problèmes sont réglés lorsque je connecte les deux équipements en Ethernet, sans aucun autre changement de config. J’ai essayé sans succès quelques modifs, telles que changer le MTU.
Y-aurait il un problème sur le switching entre le Wifi et l’Ethernet ?

Merci !

-n

Bonjour, serait-ce possible de réfléchir et implémenter une fonction de refus de connexion lorsqu’un appareil avec adresse MAC aléatoire tente de se connecter en wlan ? Compte tenu que le flag fabriquant est alors inconnu, c’est je pense réalisable d’avoir une telle fonction. La blacklist comme la whitelist sont trop contraignantes en fermant le réseau et nécessitant des actions manuelles, et le problème des MAC random est l’accumulation de doublons de périphériques inconnus. Possible ou pas, afin d’avoir un réseau propre ?

Bonjour,

Depuis plusieurs mois, certaines personnes dans la famille qui disposent encore d’un Server Révolution ont remarqué que le débit du gestionnaire de téléchargement est devenu extrêmement lent. Jamais plus de 5Mo/s, contre 25 Mo/s auparavant. Télécharger des fichiers prend donc un temps fou. Nous avons remarqué que cela est survenu au moment où le WiFi de la Freebox a été boosté, comme si des ressources matérielles avaient été retirées de la fonction NAS pour les redistribuer au WiFi.

Merci d’étudier le problème et de procéder à une correction.

Cordialement,
Romain

Bonjour, avant de rentrer dans les détails je précise que tous les tests sont conduits sur une Freebox Pop V8 WiFi 7 version 4.9.0 avec un Pixel 9 Pro XL (Android 15 QPR2 stable de mars 2025) en vue directe de la box à environ 1 mètre sans répéteur. Les 5GHz sont en 160MHz DFS et canal automatique (canal 40), et les 2.4GHz sont en 40MHz (20MHz effectif) en canal automatique également (canal 6).
Quand on active la MLO dans FreeboxOS, deux possibilités, soit le téléphone reste bloqué en 2,4GHz, soit il se connecte enfin en 5GHz (après la DFS bien sûr) mais possède un débit maximal de 700/800Mbps (au lieu de 1600/1800Mbps normalement). Si les 5GHz n’accrochent pas, redémarrer le WiFi du téléphone fait complètement planter la box et la fait redémarrer par elle-même.
Quand le MLO n’est activé que sur les 2,4GHz le débit en 5GHz reste de 700Mbps, indiquant bien un soucis avec le MLO, qu’on l’utilise ou non.
Dès qu’on désactive le MLO, les débits habituels reviennent correctement.
Surtout que j’ai pu constater que le téléphone n’arrivait parfois pas du tout à se connecter au WiFi quand le MLO est activé (J’ai même pu voir un message d’erreur inédit sur le téléphone indiquant que la box est temporairement pleine (quoi que ça veuille dire) m’empêchant de m’y connecter).
De fait, le MLO sur les Freebox Pop ne fonctionne absolument pas, le téléphone refuse de se connecter en MLO (alors que Wifiman confirme son activation) et divise les débits par deux. Le soucis de débit à été constaté sur des Galaxy S21 Ultra (par un témoignage) et Pixel 6 (Android 15 QPR2 de mars 2025), tous deux incompatibles Wifi 7 et qui ont pourtant bien vus leurs débits divisés par 2 aussi, l’activation du MLO divise donc le débit par 2 même quand on se connecte en WiFi 6.
Également, quand le MLO est activé, le Pixel 9 Pro XL ne se connecte qu’en WPA2 et non plus en WPA3 (mode WPA2/WPA3 Transition).

Bonjour !

J’ai un problème avec mes deux répéteurs wifi 7, qui se déconnectent régulièrement.

Contexte :
- Freebox Ultra, Freebox OS 4.12.3
- 2 répéteurs Wifi 7, firmware 2.7.13
- Backhaul Wifi pour les deux (pas d’Ethernet disponible à leur emplacement)
- MAC Server : 38:07:16:C2:20:31
- MAC répéteur 1 : 38:07:16:B0:85:14
- MAC répéteur 2 : 38:07:16:AE:AE:A2

Les deux répéteurs perdent la connexion avec la Freebox au bout de quelques jours de fonctionnement. Le voyant passe au rouge, le répéteur est affiché « déconnecté » dans Freebox Connect, n’a plus d’adresse IP et n’est plus joignable sur le réseau local. Il n’y a jamais de reconnexion automatique, même après plusieurs jours.

Les deux répéteurs ne tombent pas simultanément. Ils décrochent indépendamment, à quelques jours d’écart. Par exemple, actuellement :
- Répéteur 1 : dernière connexion le 27/07/2026
- Répéteur 2 : dernière connexion le 31/07/2026
- Les deux sont restés dans cet état jusqu’à aujourd’hui, sans reprise
- 09/08/2026 : redémarrage du Freebox Server. Aucun des deux répéteurs ne remonte.

Les radios du serveur semblent fonctionner, puisque 16 appareils sont toujours connectés en Wifi à la box, répartis sur la carte 2.4 GHz et sur une des deux cartes 5 GHz. Les quatre cartes affichent une courbe d’occupation du canal qui s’actualise normalement, aucune n’est en erreur.

Canaux relevés pendant la panne :
- 5 GHz / 802.11be : canal primaire 128, secondaire 124
- 5 GHz / 802.11be : canal primaire 36, secondaire 40
- 6 GHz / 802.11be : canal primaire 85, secondaire désactivé
- 2.4 GHz / 802.11be : canal primaire 1, secondaire désactivé

Je suis actuellement à distance sans accès physique à l’installation. Je ne peux donc faire ni cycle d’alimentation, ni branchement Ethernet, ni reset, ni ré-appairage par QR code. En revanche l’installation est actuellement figée dans l’état fautif, avec les deux répéteurs déconnectés donc potentiellement disponibles pour un diagnostic par logs côté serveur.

Je suis disponible pour fournir les informations complémentaires nécessaires.
Merci pour votre retour !

Bonjour, le débit de ma box ultra ne correspond pas à mon abonnement 8Gb/s symétrique.

Titre : Bridage descendant persistant à ~1.2 Gbps (XGS-PON) / Suspicion d’anomalie DBA / Interopérabilité OLT (FS#39056)

### Description du problème
Bonjour,
Abonné Freebox Ultra, je constate un bridage strict et constant de mon débit descendant (Rx) aux alentours de 1,2 Gbit/s. Le débit montant (Tx) atteint ~2,4 Gbit/s.

Ce comportement est permanent, y compris en heures creuses (testé à 04h00 du matin), ce qui exclut une saturation de l’arbre PON par la charge abonnés. Les symptômes sont en tout point identiques à l’anomalie documentée dans la tâche FS#39056.

### Diagnostics et mesures effectués (Réseau LAN validé)
En tant qu’ingénieur réseau, j’ai isolé et validé l’intégralité de ma chaîne de liaison locale afin d’exclure tout goulot d’étranglement lié à l’hôte de test :

1. Couche 1 (Optique WAN) :

• Puissance reçue (Rx) : -19.03 dBm (Plage nominale idéale).
• Puissance transmise (Tx) : +6.67 dBm.
• Synchro Freebox OS : Stable au maximum à 1000 Mo/s (~8 Gbit/s).

2. Validation de la Stack LAN & Hôte :

• Interface de test : Carte 10G connectée directement sur le port SFP+ de l’Ultra.
• Optimisations OS : RSS et LSO actifs, Flow Control (802.3x) désactivé pour éviter les Pause Frames.
• Test de boucle locale (Preuve ultime) : Téléchargement d’un fichier volumineux directement depuis le stockage NVMe local de la Freebox Ultra vers le PC de test. Débit constaté : > 300 Mo/s (soit > 2,4 Gbit/s réels). Le switch interne Cortina et la stack IP du PC valident donc parfaitement le Rx au-delà du palier constaté sur le WAN.

3. *Mesures WAN (nPerf / iPerf3 multi-flux) (même constat en téléchargement sur http://test-debit.free.fr/):

• Download (Rx) : Plafonne systématiquement à 1200 Mbit/s.
• Upload (Tx) : Atteint 2400 Mbit/s.

### Conclusion & Demande
La couche physique optique étant irréprochable et la stack locale (LAN/PC) ayant prouvé sa capacité à dépasser les 2,4 Gbit/s en Rx depuis le NVMe, le problème est localisé sur le segment WAN/infrastructure.

Il s’agit très probablement d’un défaut d’interopérabilité OMCI ou d’une mauvaise gestion de l’allocation dynamique de bande passante (DBA) entre le chipset Cortina de l’Ultra et l’OLT du NRO (Nokia/Huawei).

Je sollicite une escalade auprès de l’équipe d’ingénierie réseau de niveau 2/3 afin de vérifier le provisionnement de mon profil et les files d’attente (queues/SLA) sur l’OLT de mon secteur.

Merci d’avance pour votre analyse.

Cordialement

Bonjour,

Je suis possesseur d'un Freebox Ultra et souhaite obtenir la valeur du "signal" wifi en dbm des répéteurs wifi (connectés actuellement en wifi avec la freebox).
En effet via l'api /lan/browser dans le champ 'access_point', je peux récuperer les infos des stations (notamment la qualité du signal en dbm entre la station et le répéteur) mais pas pour les répéteurs (signal wifi entre la freebox et le répéteur).
L information remonte bien dans l'appli smartphone donc j'imagine que l on peut l'obtenir via l api.

Merci de votre retour.