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

Ce projet correspond aux anomalies ou aux demandes d’évolutions logicielles pour le Freebox Server.

Pour des problèmes de ligne ADSL ou Fibre, vous devez vous adresser directement au 3244.
N’indiquez ici que les bugs ou les demandes d’évolution concernant le Freebox Server.

Pour les remarques concernant le Freebox Player Révolution (V6), vous pouvez le faire sur la page dédiée.
Pour les remarques concernant la Freebox Mini 4K, vous pouvez le faire sur la page dédiée.
Pour les remarques concernant le Freebox Player Devialet (V7), vous pouvez le faire sur la page dédiée.
Pour les remarques concernant le Freebox Player Pop (V8), vous pouvez le sur la page dédiée.

Effectuez la mise à jour de votre Freebox Server vers la dernière version annoncée sur l'historique des mises à jour Freebox Server

Vérifiez que votre problème ou votre demande d’évolution n’a pas déjà été posté auparavant.

Merci d’avance.

ID Ouverte Type Catégorie Système d'exploitation État Résumé  desc
3367806/01/2021ÉvolutionNon triéTousNouveauZFS pour tous ? Oh oui, oh oui !!!! Description de la tâche

Ma demande est totalement lunaire, je le conçois mais....

ZFS pourrait très bien être le système d’exploitation presque universel de demain.

- ZFS marche très bien sur FreeBSD (et Solaris bien entendu qui est son OS d’origine)

- ZFS a été implémenté sur Linux via OpenZFS, sa prise en charge est désormais très très avancée sur certaines distros, prise en charge à un état de maturité bien supérieure à BTRFS qui reste ultra expérimental, au point que Ubuntu a décidé de l’implémenter par défaut en lieu et place de BTRFS

OpenZFS est disponible en beta version sur canaux alternatifs sur openSUSE Tumbleweed tant sur plateforme x86 qu’ARM

- Mais surtout surtout.... OpenZFS a été porté sur Windows.

https://openzfs.org/wiki/Main_Page https://github.com/openzfsonwindows/ZFSin

Le portage sous Windows n’est pas un vulgaire portage via Dokan (l’équivalent Windows de FUSE) comme ça a pu être le cas sur des projets précédents, il s’agit d’un driver NATIF dont l’état de développement est très avancé. Ce driver promet donc une prise en charge à quasi identité avec les projets OpenZFS sur Linux, ou ZFS sur FreeBSD, c’est un projet opensource et GRATUIT

J’ai installé ZFS sur mes PCs, j’ai déjà expérimenté des échanges entre Linux, Windows... c’est juste bluffant, même si tout n’est pas encore parfait.

Windows a perdu son driver ext2/ext4 car extfsd n’est plus développé, le support s’arrête à Windows 7
La seule solution en lecture écriture reste une solution payante Paragon basée sur Dokan, donc ce n’est qu’un vulgaire systeème FUSE avec toutes ses limitations. De plus Dokan étant utilisé par d’autres logiciels comme Cryptomator, Seadrive, on se retrouve parfois avec des conflits inextricables de driver Dokan, des BSOD donc exit Paragon, on se contentera de lire les volumes Ext2/3/4 en lecture seule gràace à LinuxRead

Un disque USB en ZFS, la grappe raid de la Freebox qui serait alors en ZFS et non plus en mdm, pourraient être indifféremment réimportés vers des systèmes FreeBSD, Linux, Windows avec une performance NATIVE

Autre avantage ZFS implémente par défaut le système de droits NFSv4 complètement compatible avec le système de droit NTFS de Windows, ce qui faciliterait encore plus la transportabilité des données, permettrait de gérer avec plus de finesse les droits sur le serveur Samba de la box

Samba dans ses dernières impplémentations offrent l’option de système de fchier ZFS pour tirer partie de sa gestion native de NFSv4

ZFS ne remplacera pas NTFS, EXT4, FAT32... pour de multiples raisons assez complexes comme le fait que ZFS est aussi par nature un gestionnaire de volume qui peut donc entrer en conflit avec certains matériels comme les faux raid matériel.

ZFS est au départ conçu pour des énormes serveurs de données, et la gestion en direct de grappes RAID... mais de façon inattendue suite au projet OpenZFS on Windows, ZFS peut donc devenir l’alternative universelle de demain même pour l’usager lambda. Il faudra juste sous Windows que des gens développent des interfaces graphiques pour la configuration et la maintenance de ZFS

3501108/06/2021ÉvolutionNon triéFreebox Server V7 (Delta)NouveauSoft power down Description de la tâche

Il serait temps d'implémenter une procédure de soft power down.

Pour éteindre une Freebox on la débranche à l'arrache… ce qui est possible lorsque la Freebox n'a pas de disques mécaniques.

Avec un disque mécanique il y a toujours une probabilité certes faibles, qu'une extinction à l'arrache se fasse au pire des moments et engendrent une détérioration des données irréversibles.

Des utilisateurs qui renvoient leur Freebox Revolution avec disque out, IL Y EN A PLEIN, ce n'est pas une majorité certes, mais cessez de vous voilez le visage, les disques dur mécaniques qui lâchent ça existe bel et bien.

La faible capacité de la Revolution faisait que personne ne s'en servait comme un NAS, donc pas de données critiques le DD de la Révolution était juste un cache de données.

Avec la Delta TOUT CHANGE, et il faut que les développeurs ACCEPTENT D'EN PRENDRE CONSCIENCE.
Il existe des disques dur mécaniques de 2.5 pouces en 5 TO, donc théoriquement le Delta peut gérer un NAS de 20 TO

Le nombre de disques augmentant le risque de pertes de données irréversibles liées à une coupure brutale EST NETTEMENT PLUS ELEVEE
Ajoutons qu'avec 20 TO, là on parle d'utilisateurs qui gèrent des données sensibles car on ne rebatit pas une bibliothèque de 20 de données comme cela.

L'implémentation d'un soft power down pour éteindre définitivement la Freebox (ou a minima la mettre en veille et autoriser une déconnexion de la prise haute tension en toute sécurité) me parait indispensable

Dans un soft power down commandé via l'écran tactile ou via Freebox OS, l'OS va achever toutes les opérations en cours ou les terminer proprement, vider tout son cache d'écriture sur les disques dur, il va commander le parquage des têtes de disques dur dans un endroit sûr, et va enfin demander au BIOS d'éteindre la machine.

C'est ce qui se passe sur un PC de monsieur tout le monde. Toute le monde sait qu'éteindre brutalement un PC peut conduire à des choses plus ou moins catastrophiques, même si statistiquement, NTFS, Ext4 se révèlent assez robustes (pour EXT4 il faut bien ajuster ses paramètres et notamment choisir l'option de montage data=journal, l'option par défaut choisie par nombre de distributions data=ordered EST TOTALEMENT INSUFFISANTE)

La Delta étant plus compacte que la Revolution en ces jours d'été venant, elle est sensiblement plus bruyante vu que les ventilos tournent toujours à fond. Les gens peuvent être tenté d'éteindre cette machine quand ils se couchent si ça les gêne pour dormir, donc les opérations d'extinction à l'arrache pourrait se multiplier durant la période estivale et causer un nombre sensible de déconvenues en terme de pertes sèches de données.

3494430/05/2021AnomalieLANFreebox Server V7 (Delta)En attente de réponseSMBv2 - Suppression du SMB1 et Modification non sollici... Description de la tâche

1) Suppression du protocol SMB1

L'activation du SMBv2 rend inactif le SMBv1 contrairement à ce qui était sous entendu sur la page principale de votre site, sauf si j'ai mal compris.

J'ai personnellement encore certains zinzins qui ne se connectent qu'en SMBv1, alors que Windows 10 et Linux réclament le SMBv2 par défaut, mais bon…. je ne dois pas être un cas commun. Outre les problèmes de sécurité du SMB1, le SMB2/3 est quand même plus performant, d'où l'intérêt que j'aurais à mixer les protocoles.

En fait j'ignore si l'activation simultanée des 3 protocoles est vraiment possible, je n'ai pas encore fait de test approfondi sur mes systèmes, mais j'avais cru voir dans la doc "Samba" les paramètres min et max protocol de /etc/samba/smb.conf

Donc si on place

min protocol = SMB1
max protocol = SMB3

Théoriquement le serveur pourrait accepter l'authentifcation cumulée selon les 3 protocoles….. sous réserve de tests. Peut-être que le cumule n'est possible que sur les deux derniers protocoles…

Dans tous les cas, ça pose un souci.
Pour des raisons de sécurité certaines personnes ne veulent absolument plus que le serveur serve le protocole SMB1 (c'est juste moi qui suis dans un cas particulier et j'assume le risque qui va avec), donc placer min protocol à SMB2 semble répondre à la demande majoritaire.

Pour résoudre le problème des gens qui pour certaines raisons ont besoin des protocoles cumulés 1, 2, 3 ça implique donc que l'interface Freebox OS soit modifiée.

La Freebox par défaut active les protocoles 2/3 et on a une case à cocher SMB1, qui permet explicitement d'activer le SMB1 EN PLUS (avec un petit écran d'avertissement sur les problèmes de sécurité induits) si tant est que le cumul des 3 protocoles est vraiment possible.

Bien entendu, lors de la mise à jour, pour ne pas disturber les utilisateurs la case SMB1 est automatiquement cochée si un serveur est déjà paramétré selon ce protocole, mais pour les nouveaux clients, la box doit décocher par défaut le SMB1 et activer par défaut SMB2 / SMB3

2) Modification des noms de partage

Lorsque l'on active le SMBv2, il semblerait que le serveur Samba de Freebox OS modifie les noms de partage contenant des majuscules en passant tout en minuscule. Si ce n'est pas en soit critique, c'est ennuyeux car ça implique de modifier tous les informations d'identification au niveau des clients.

Dans les standards Windows, contrairement à Linux, les minuscules et majuscules sont discriminantes par défaut. En revanche je ne sais pas ce qu'il advient des caractères accentués… en effet, dans l'univers Windows l'utilisation de noms de partages contenant des caractères accentués est monnaie courante, contrairement au monde Linux.

Il faut donc s'attendre à ce qu'un nombre important de réclamations alléguant l'impossibilté de se connecter viennent d'un changement de casse.

Normalement c'est un simple paramètres dans Samba qui indique si minuscules et majuscules sont discriminantes.
Du reste, il suffit de revenir en SMB1 et comme par magie tout revient en ordre.

NB : Pour rappel la fameuse faille de sécurité ne conduit pas directement à un black out du PC. Le virus par définition doit être activée sur un poste client via par exemple une pièce jointes d'un email, et le virus s'il détecte la présence de serveurs Samba SMB1 va exploter la faille pour se diffuser à travers tout le réseau. Le risque est donc essentiellement pour les entreprises qui peuvent voir tous les postes de l'entreprise progressivement infectés

 34914 24/05/2021ÉvolutionWiFiFreebox Server V7 (Delta)Fermée Radio WiFi 5 ghz et 2.4 ghz : possibilité d'activation  ... Description de la tâche

Il serait intéressant d'ajouter la possibilité de désactiver indépendamment les 3 radios ou disons au moins de pouvoir activer/désactiver de façon indépendante les radios 2.4 Ghz et 5 Ghz.

Je rappelle que dans des environnements exigus avec une forte concentration d'objets réfléchissants, le 2.4 Ghz pose de sérieux problèmes car il entre conflit avec les appareils bluetooth, les DECT, les périphériques sans fils…

A la différence du 5 ghz, le 2.4 Ghz a un pouvoir pénétrant considérable, ainsi qu'une grande portée, voilà pourquoi lorsqu'un appareil Wifi émet à forte puissance, il crée des perturbations importantes. Il est impossible de faire fonctionner correctement de façon simultanée le Wifi 2.4 ghz avec un périphérique bluetooth de type casque, sans parler d'un véritable bordel dans certains cas où même les claviers sans fils ne fonctionnent plus.

J'ai testé un nombre considérable de matériels Bluetooth qui n'ont jamais fonctionné correctement chez moi.
Le salut je l'ai trouvé avec l'apparition de la bande Wifi 5 ghz d'une part, et d'autres part avec les dernières cartes Wifi Intel (AX200) qui embarquent un protocole bluetooth 5.0 prenant en compte ces problèmes de perturbations et offrant une gestion plus intelligente de la puissance. Tout n'est pas parfait, mais j'arrive enfin à faire fonctionner un casque bluetooth de façon satisfaisante… mais à condition qu'aucun appareil Wifi 2.4 ghz ne soit actif à proximité

Comme basculer le Wifi sur le 5 Ghz exclusivement constitue la solution, du coup il serait intéressant de pouvoir couper une fois pour toute la radio 2.4 ghz au niveau de la Freebox, afin de libérer totalement la bande passante au bluetooth

Le Wifi 2.4 ghz ne pose aucun souci en revanche dans de grandes maisons ou de grands appartements, hors environnement urbain.

Je ne pense pas être un cas si exceptionnel. C'est simplement que ces problèmes ne sont jamais ouvertement évoqués pour des raisons marketing, par ignorance et je m'en foutisme des uns et des autres.

Donc cette demande d'évolution est plus importante qu'il n'y parait… à condition que des gens se remettent enfin en tête les bases même de la radio et des problèmes d'interférences afin de proposer les meilleures solutions en fonction des environnements.

Encore une fois, je ne suis pas un cas isolé, simplement il y a beaucoup de gens qui ne connaissent pas l'origine du problème.

 35164 06/07/2021AnomalieWiFiFreebox Server V7 (Delta)Fermée Plantage de la troisième radio Wifi  Description de la tâche

Depuis l'application du firmware 4.4.0, je constate un plantage aléatoire de la troisième radio Wifi

En préambule, cela ne concerne que la Freebox Delta Server qui possède un Wifi AC 3 bandes, 1 bande N 2.4 Ghz (radio 1) et deux bandes AC de 5 Ghz (radio 2 et 3) pouvant chacune fonctionner avec canaux DFS sur une largeur de bande de 160 mhz si les conditons le permettent

Mes trois radios sont paramétrés sur un SSID différent et masqué.
Je répartit mes appareils sur les 3 SSID, pour équilibrer la charge

Symptômes :

De façon inopinée, le Wifi des clients connectés à la troisième radio se coupe subitement, la connexion est coupée avec la radio
Sachant qu'il n'a aucune appareil connecté à la radio 2, il y a juste un iphone connecté sur la radio 1, mais c'est un iphone en veille qui se contente juste de récupérer régulièrement mes mails. L'iphone n'effectue aucune opération lourde et du reste ça fait très longtemps que ça marche sans causer de pertubation sur les appareils qui se connectent sur les bandes 5 ghz

Si on inspecte l'interface Freebox OS on consate :

- le Wifi 2.4 GHz n'est pas concerné, la radio fonctionne normalement, les clients ne sont pas coupés
- Lorsque l'on tente de s'authentifier sur la radio 3, impossible, apparemment la radio n'émet plus de signal
- Le PC arrive en revanche à se connecter manuellement sur les Radio 1 et 2

Dans l'interface Freebox OS, l'état de la Radio 3 semble normal, elle est en statut activé, sauf que bine entendu il n'y a plus de client connecté, mais en réalité cette radio est plantée. Si on la reconfigure comme par exemple pour rendre à nouveau visible le SSID, Freebox OS valide correctement l'opération, mais ça n'a aucun effet, ce qui semble bien confirmer que la radio est planté, et qu'elle n'émet plus rien du tout.

Pour remédier au problème, il faut couper totalement le wifi et le réactiver pour forcer le redémarrage total de la carte, sauf que le maintien de la connexion reste aléatoire dans la durée.

Ca peut fonction 2/3 heures et couper sans prévenir, et il faut renouveler l'opération, ça peut intervenir dans l'après midi, comme en soirée

Lorsque la carte Wifi redémarre, les 2 radio Wifi 5 Ghz se placent systématiquement ET SANS AUCUN PROBLEME en 160 mhz de largeur de bande, ce qui montre clairement que la bande locale n'est pas perturbé par des réseaux voisins qui de toutes les façons sont majoritairement en 2.4 ghz, je dois être le seul dans l'immeuble à utliser le 5 ghz

Avant le firmware 4.4.0 je n'avais pas ce problème. Mon PC principal pouvait tenir toutes la journée connectés en continue SANS AUCUN PROBLEME, je pouvais connecter ponctuellement un second appareil sur la même radio (ou même SSID) sans que ça pose problème.

Il y a toujours la possibilité que la carte Wifi de la Freebox montre des débuts de fatigues mais :

- péter une seule radio d'une carte Wifi, c'est un phénomène assez rare, en général c'est toute la carte qui tombe en panne

- la coincidence des événements avec l'application du firmware 4.4.0 est quand même très trés étrange

- ma Delta a déjà été changée l'année dernière (des régulateurs de tension qui avaient lâché et coupé l'alimentation des ventilos et des disques dur), je n'ai pas spécialement envie de l'échanger à nouveau (ça m'oblige à reparamétrer mes pare-feu qui détectent l'adresse MAC de la Freebox)

Il y a peu de chances qu'il y ait un problème matériel chez moi, le firmware 4.4.0 contient à mon avis une modifications qui doit être à la source de cette regression

 35163 06/07/2021AnomalieNon triéTousFermée Freebox OS: Augmenter le contraste et réduire la lumino ... Description de la tâche

Le nouveau thème que vous avez appliqué avec le firmware 4.4.0 est trop clair et manque de contraste.

Les textes de confirmation apparaissant en arrière plan en grisé sur les icônes de validation d'action comme "OK", "APPLIQUE SONT GENERALEMENT ILLISIBILES DU FAIT DE FORTE LUMINOSITE DES ECRANS LCD"

Sincèrement, on en a rien à cirer que l'interface freebos OS soit super esthétique.

L'ancienne présentation avait un énorme avantage

ELLE ETAIT PARFAITEMENT LISIBLE

On s'en fout d'avoir des thèmes hyper rock'n roll, on veut l'efficacité en priorité.

Merci de rebasculer sur l'ancien thème en attendant éventuellement de revoir certains aspects ergonomiques des nouvelles icônes, réétudier l'interface et les contarstes de couleurs.

Je suis à chaque fois obligé de coller mes yeux sur l'écran pour deviner ces putains de textes en arrière plan avec des nouveaux jeux d'Îcônes qui sont loin d'être intuitifs.

 35027 10/06/2021AnomalieNon triéFreebox Server V7 (Delta)Fermée Bridge Windows - Fuite d'adresses MAC phyisques  Description de la tâche

Mes PC sont configurés en bridge failover.
Ca consiste à bridger l'interface Wifi et l'interface Lan filaire.

Sous Linux : pas de souci


Si l'une des interfaces coupe, l'autre prend le relais, mais elles ne fonctionnent jamais ensemble, l'avantage est que les adresses IPv4, IPv6 sont maintenues donc il n'y a jamais d'interruption de flux pour cause de changement d'adresse IP locale.

Il s'agit bien de failover, pas de bridge LACP pour combiner deux lignes et augmenter la bande passante.

Le bridge Linux ou "bond failover" se comporte comme attendu. Il masque totalement les adresses physiques des interfaces Wifi ou Lan avec sa propre adresse MAC qui génère donc sa propre adresse de lien locale IPv6 qui ne bouge jamais

Qui plus est sous Linux je peux choisir ma ligne master. Ici je préfère le Wifi au Lan, car le WIfi 5 ghz marche très très bien et surtout il n'y a qu'un nombre limité de port Ethernet physique sur la box, c'est juste le soir, j'ai programmé une coupure du Wifi mais si je veux veiller plus tard alors je bascule automatiquement en Lan sur un petit switch gigabit (switch qui aura tendance a saturer si trop de clients se connectent, d'où l'intéret d'utiliser en temps normal la pleine bande passante du WIfi)

Sous l'interface Freebox OS, que je sois en Wifi ou Lan, c'est toujours le même PC avec la même adresse MAC qui apparait, la MAC du bridge. Il faut alors inclure cette adresse Mac dans la liste blanche des adresses MAC Wifi pour autoriser la connexion sans fil

Donc tout est parfait dans le meilleur des mondes

Sous Windows : c'est un sacré B O R D E L


Windows par défaut alterne Wifi / Lan en préférant le LAN, mais par défaut ça génère chaque fois une nouvelle adresse locale.
L'astuce est donc de bridger la carte Wifi et la carte LAN, et ensuite dans le gestionnaire de périphérique on impose une adresse MAC au bridge. Si on ne fait pas cela, l'adresse MAC du bridge a tendance à alterner suivant les démarrage en prenant tantôt l'adresse de la carte Wifi, tantôt l'adresse de la carte Lan
Vous savez ce que signifie "bridge" donc dès lors qu'une interface est bridgée la MAC adresse du bridge est censée avoir la priorité sur l'interface physique….

1 ) Quand on bascule de Wifi à Lan :

FreeboxOS

Le DHCP Freebox attribue une adresse IPv4 à la MAC adresse physique de la carte réseau car cette dernière n'est pas la même que l'adresse du bridge. Mais cette adresse ne semble pas transmise à Windows (voir ci-après)
Dans les caractéristiques de connexion Freebox OS, dans l'historique de connectivité de la carte LAN du PC, Freebox OS est incapable de rapatrier les données IPv6, et ne fournit qu'une adresse IPv4

Windows
Sous Windows au niveau du bridge on est toujours sur l'ancienne adresse IPv4.. donc après un test je confirme qu'on peut pinger 2 adresses IPv4, celle du bridge qui n'a pas bougé, et celle de la carte Lan (cf paragraphe ci-dessus), c'est bien sûr anormal et c'est peut-être la source d'une instabilité sous Windiws qui de temps en temps crashe avec un BSOD qui met en cause le driver bridge.sys

Les données IPv6 disparaissent et réapparaissent quelques minutes après
Adresse de lien local : OK elle ne disparait jamais et en fait c'est normal
Adresse IPv6 fixe. De façon logique, elle ne bouge pas puisque qu'elle est calculée en fonction de l'adresse MAC du bridge (et à conditon d'avoir activé l'EUI64 sous Windows ce qui n'est pas fait par défaut, sous Windows par défaut les adresses de lien locale peuvent varier à chaque redémarrage)
Adresse IPv6 temporaire : celle-ci ne semble pas bouger, c'est un comportement normal

2) Quand on bascule de Lan à Wifi

FreeboxOS
Le DHCP Freebox n'attribue probablement pas d'adresse IPv4 liée à l'adresse physique de la carte WIfi car l'adresse IPv4 qui s'affiche semble toujours synchrone avec celle affichée au niveau du bridge Windows contrairement à la situation précédente.
Donc le DHCP semble probablement lier cette adresse à l'adresse MAC du bridge, ce qui est un comportement normal
Les données IPv6 au niveau du lien local et de l'adresse IPv6 fixe sont celles du bridge Windows, ce qui conforteraient encore l'hypothèse précédente.

Au niveau du filtrage MAC… il faut renseigner la MAC adresse physique de la carte, alors que dans un bridge parfait comme celui de Linux, il faut renseigner l'adresse MAC du bridge

Windows
Adresse IPv4 : l'adresse IPv4 transmise par la Freebox est attribuée au bridge. Pour Windows, la MAC adresse physique est transparente.

les données IPv6 disparaissent et réapparaissent
Adresse de lien local : OK même remarque ça ne bouge pas
Adresse IPv6 fixe : OK idem
Adresse IPv6 temporaire : à chaque bascule sur le Wifi, une nouvelle adresse IPv6 temporaire est générée ce qui n'est pas normal (sous Linux…. ça ne bouge pas)

Conclusions
Sous Wifi tout semble bien fonctionner, sauf le fait qu'à chaque nouvelle connexion Wifi il renouvelle l'adresse IPv6 temporaire, ce qui peut donc conduire à une coupure du lien internet, or la continuité des adresses IP c'est ce qui est par essence recherchée à travers un bridge failover.

Impossible toutefois d'affirmer s'il s'agit d'un souci Windows ou si cela vient d'une interaction avec la Freebox, car la notion de bridge failover n'est pas implémentée telle quelle sous Windows, c'est une notion Linux/BSD.
Cela peut-être lié au Wifi uniquement du fait qu'il y a une procédure d'identification

Sous Lan c'est un peu le souk car la Freebox attribue une adresse IPv4 propre à l'adresse MAC de la carte, qui conduit à un doublonnage d'adresse et ets peut êtreà la source d'un rpoblème d'instabilité sous Windows avec de temps en temps un BSOD avec un message mettant en cause le driver bridge.sys

Les bridges Microsoft, ça existe depuis longtemps, Windows 2000 connaissait déjà cela, je serais quand même surpris que Microsoft ait foiré quelque chose.
Il est fort probable que le bridge Windows par rapport au bridge Linux ne masque pas totalement l'adresse MAC des interfaces physique, les deux adresses MAC sont à mon avis transmises dans la trame.

Il faut donc que la Freebox analyse les paquets pour ne prendre en compte que l'adresse MAC du bridge, et de ce fait on aura un comportement parfaitement similaire à un hôte Linux, soit un hôte unique et distinct des interfaces physiques
Reste que ça ne résoudra peut-être pas le problème de ce renouvellement d'adresses IPv6 quand on bascule sur le Wifi, il peut s'agir d'un problème spécifique à Windows vu que par essence avec le SLAAC, ce sont les hôtes qui s'auto-assignent les adresses IPv6, pas vraiment le routeur, mais ça résoudrait peut-être le problème de stabilté de Windows qui trouverait sa source dans une double attribution d'adresse IPv4

Avec l'apparition de votre Freebox Pro, les utilisateurs susceptibles d'utiliser des bridges Windows notamment à travers des Windows Server, pourraient se multiplier donc à mon avis il y a urgence à régler ce problème, voilà pourquoi j'ai placé cette anomalie comme critique.

 34220 03/03/2021ÉvolutionLANTousFermée Assignation adresse IPv6 locale fd00:://64  Description de la tâche

Attribuer au routeur Freebox une adresse IPv6 additionnelle dans la plage fd00::64 L’idéal serait d’attribuer l’adresse via un le suffixe 64 bit du lien local IPv6 de la Freebox (fe80:x:x:x:x64)

Sauf erreur de ma part, il n’y pas encore si longtemps la Freebox Revolution était accessible via l’adresse fd00::1
Cette addresse a disparu sans que je sache si c’est dû à une évolution du firmware ou à ma migration vers la Delta

Néanmoins l’adresse fd00::1 est une solution E X E C R A B L E.
fd00::1 est une adresse bateau qui peut être utlisée par défaut par pas mal d’équipements en cours de configuration, mais surtout dans le cadre d’un multi-abonnement, un client Free peut se trouver avec deux Freebox ayant la même adresse… donc il y a un problème.

La solution que je propose est la meilleure solution possible
C’est une adresse prédictible et unique à chaque Freebox. Le lien local v6 étant lui même unique calculé sur la base de l’adresse MAC via le protocole EUI64

Pour les gens qui ne voient pas l’intérêt de ce scope….

Les adresses dans le scope fc00::/7 incluant fd00::/64 sont des adresses privatives non routables sur internet donc équivalentes aux adresses privatives ipv4 du type 192.168.x.x.

Sur des services qui n’ont pas vocation à servir en dehors du réseau local, il suffit d’assigner au serveur une adresse dans le scope fd00::/64 au lieu d’une adresse ipv6 avec le préfix global de Free en 2a01:x:x:x//64. Ainsi il n’y a absoluement aucun risque d’un accès via l’extérieur même si le pare feu est désactivé pour des raisons de maintenance.

Il faut bien sûr assigner aux clients une adresse dans le scope fd00:://64
Il peut arriver, et il arrivera sans doute de plus en plus souvent, que certains clients n’implémntent que la couche IPv6, dans ce cas l’adresse locale dans le scope indiqué est généralement nécessaire

Tâches 1 - 8 sur 8 Page 1 sur 1

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche