Tous les projets

Cette demande remonte à la nuit des temps, depuis que Freebos OS existe
C’est régulièrement réclamé sans jamais de réponse de votre part

Veuillez prendre connaissance de ce fil. Sauf erreur de l’utilisateur dans l’interprétation des instructions, Coriolis lui demande de forwarder deux plages d’adresses de 30 hôtes (masque CIDR 27) sur deux plages de port, ce qui ferait théoriquement 120 règles à se cogner.

https://forum.universfreebox.com/viewtopic.php?p=770980#770980

La solution de contournement consistant à sélectioner “toute adresse” dans IP source n’est pas acceptable

Cette demande de fonctionnalité est CRITIQUE, vous ne pouvez plus vous cacher derrière votre Index

Comment l’implémenter :

- il serait préférable de choisir un format de type “range” adresse de x.x.x.x à x.x.x.x (contigues par définition).
En effet un bloc d’adresses à forwarder ne correspond pas obligatoirement à un masque sous réseau standard
Parallèlement on peut toujours ajouter une seconde option d’entrée via masque de sous réseau CIDR ou classique, mais la méthode “range” doit être dans tous les cas implémentée

- dans sélection du protocole il faut ajouter l’option “TCP et UDP” Si l’utilisateur doit en entrer un nombre important de bloc d’adresses non contigues, et les forwarder en UDP et TCP, ça permet de diviser son travail de saisie par deux.

NOTE : et au passage il est rappelé que la possibilté de forwarder et redirigier des plages d’adresses IPv6 a déjà été demandée plusieurs fois. La demande n’est certes pas critique, il suffit de ne pas activer le pare feu IPv6 réseau de la box, mais certaines personnes aimeraient bien pouvoir profiter d’une protection en amont de la Box en IPv6 et IPv4, considérant que ça rentre dans une de ses fonctions de base.

Ce matin tout semblait bien fonctionner.

J’accède à mon partage Samba sans problème particulier, mes deux rails Wifi 5 GHZ sont bien en bande effective de 160 mghz, alors que je m’attendais à ce que la ligne radio DFS soit restreinte à 40 mhz, comme ça se produisait régulièrement ces derniers jours (voir ma précédente remontée de bug).

Etant précisé qu’on parle d’un transfert de fichier de quelque kilo octets, pas d’un transfert de gros fichier
Je visionnais et uploadait des fichiers de configuration Linux…rien ne bien méchant

Puis quelques minutes plus tard sur une deuxième tentative d’accès… patatras plus d’accès, freeze

J’investique et je constate UN GROS PLANTAGE au niveau du Wifi

- le PC (Linux) semble toujours connecté au Wifi de la box. Je fais une tentative d’update des repos sans aucun problème particulier, juste que Samba ne fonctionne plus, si j’essaie d’accéder au partage ça provoque un freeze. Comme j’étais en mode CONSOLE phyisque, je ne pouvais pas me connecter à l’interface web Freebox OS, donc je me tourne vers mon téléphone Android qui est connecté en Wifi

- Au niveau d’Android c’est là où ça devient intéressant

L’application Freebox n’a plus un accès complet à la Freebox, mais partiel.
L’accès au gestionnaire de fichier fonctionne que ce soit sur le disque interne ou la carte SD externe qui correspondent à deux partages SMB distincts, ce qui prouve que ça n’a aucun rapport avec un éventuel problème de NAS

Mais lorsque je veux visionner l’état du Wifi… l’appli tourne dans le vide.
Impossible d’accéder aux paramètres, l’appli freeze, alors même que quelques minutes auparavant j’avais bien eu accès à ces mêmes paramètres.

Je ferme l’appli et retente pour être sûr, même chose.

Je tente de lancer Freebox Files… l’appli freeze et ne démarre pas.
Mais, de mémoire il me semble que Freebox Connect se lance correctement, mais impossible ensuite d’accéder aux paramètres Wifi

Donc je n’ai pas le choix, je dois rebooter la Delta sans savoir exactement dans quel état réel était le Wifi puisqu’il semblait continuer à fonctionner partiellement, le PC restant toujours connecté et ayant une visibilité sur le Web

Avant la MAJ 4.7.4, jamais une telle chose était arrivé, au grand jamais, croix de bois, croix de fer….
Après la MAJ 4.7.4, cet incident s’est déjà produit 3 fois de façon totalement aléatoire, et sans que jamais à ce moment précis Samba ne soit sollicité sur un très gros efforts.

La question est maintenant de savoir entre l’oeuf et la poule qui est né le premier.

Est-ce un bug de Samba qui provoque le crash du Wifi ? La veille au soir, j’avais en effet effectué une grosse tâche de transfert sur plusieurs fichiers de 2 GO, sans problèmes apparents. Mais si vous lisez certains rapports de bug précédents il est avéré que sur la Delta, parfois Samba, suite à de gros transferts, reste dans un état “incertain”. Il semble fonctionner, mais il provoque des anomalies bizarres du genre répertoire pas à jour, impossible d’écrire… il faut relancer le serveur Samba.

Donc je ne peux totalement exclure que suite à ces gros transferts de la veille… Samba était en effet dans un état “incertain” comme décrit dans des rapports de bug précédents.

Ou est-ce une problématique Wifi qui provoque des soucis sur Samba ?

J’aurais tendance à pencher pour cette hypothèse. Les Devs ont manifestement “bidouillé” quelque chose au niveau du Wifi, car avant la MAJ 4.7.4, jamais je n’avais connu de tels crashes comme décrit présentement. La seule chose que j’avais constaté, ainsi que d’autres utilisateurs, c’est que de temps à autre Samba se mettait dans un statut incertain avec un fonctionnement qui “buggue” suite à des grosse tâches (sauvegarde VSS de type Acronis, Reflect… ) et qui impose le redémarrage du serveur Samba sans provoquer plus de dysfonctionnements au niveau de la box, l’accès aux paramètres Wifi via l’appli Android Freebox fonctionnant toujours… contrairement à ici

De plus avant la MAJ 4.7.4, la disparition subite des partages SMB ne se produisait ABSOLUEMENT pas, et ça été signalé plus d’une quinzaine de fois.

Soit vous connaissez l’origine du bug et un firmware correctif est en route… Soit c’est toujours en cours d’investigation… la situation DEVIENT TOTALEMENT INTENABLE ET INACCEPTABLE vu que la Delta est baucoup utlisée pour son NAS réseau, si l’on se réfère à des personnes qui perdent les partages Samba plusieurs fois d’affilée en l’espace de quelques heures.

Dans ce cas, en attendant la résolution du problème, je pense qu’il faut rétropédaler le firmware vers la version précédente 4.7.3

J’ai l’intime conviction que l’origine des soucis “récents” vient de certaines modifications au niveau de la gestion du Wifi.
Ca n’expliquera toujours pas l’instabilité chronique de Samba après un “stress” du serveur, bug rapportée avant le firmware 4.7.4, mais on retrouvera une situation plus acceptable.

Je rouvre un sujet car répondre à un sujet ouvert et dupliqué 15 fois, ça ne sert pas à grand chose, il y a 0% de chance que les DEVS lisent mon message

Résumé :

Depuis la MAJ 4.7.4 il est désormais avéré que SAMBA crashe de façon aléatoire sans qu’il soit possible de déterminer les conditions exactes du crash. Chez certaines personnes, ça semble arriver assez fréquemment, plusieurs fois par jours, chez d’autres comme chez moi, c’est totalement aléatoire, c’est arrivé 3 fois.

Mais… il semblerait que ça se produise chez moi de préférence en soirée.
Or en soirée j’ai remarqué ces derniers temps que je perdais de façon systématique ma deuxième radio wifi 5 ghz

Pour être plus exact :

- durant la journée mon Wifi fonctionne en largeur de bande 160 mhz sur les deux bandes 5 ghz, la bande des 2.4 GHz est inactive
De temps en temps, la deuxième radio 5 ghz décroche et passe en 40 mghz de largeur effective de bande, mais ça reste un pphénomène rare DURANT la journée

- en soirée de façon moins aléatoire, mais encore aléatoire, la deuxième radio 5 Ghz (DFS) passe à une largeur de bande effective de 40 mhz au lieu de 160 mhz. Je suis obligé de redémarrer la radio le lendemain pour retrouver la pleine bande.

Ce phénomène a longtempts été complètement aléatoire… il est devenu systématique, càd toutes les soirées, sans que j’en connaisse la raison

- soit l’action de voisins qui de façon plus systématique qu’avant allument des réseaux wifi 5 gz en soirée
- soit le résultat d’un bidouillage du firmware, dans ce cas ça pourrait avoir un lien avec le firmware 4.7.4

Mon intuition est que ces problèmes de crash de Samba pourraient avoir un lien indirect avec la gestion du Wifi.
Je serais tenté de penser que lorsque la box est contrainte de modifier la largeur de bande effective d’une radio, c’est là qu’il y aurait une forte probabiblité de plantage de Samba, ce qui expliqeurait que chez moi le crash de samba se produisent plutôt en soirée.

Si le phénomène se produit plus souvent chez certaines personnes, ce sont peut-être des personnes qui sont dans des environnements Wifi plus perturbés, des personnes qui peut-être utilisent encore le 2.4 ghz, une bande devenue problématique.

C’est une piste à creuser pour résoudre un problème qui empoisonne la vie de pas mal d’utilisateurs depuis la MAJ 4.7.4, même si chez moi la situation est vivable.

Et Sainte Marie, au nom du ciel…. encore une fois cessez d’être sourd, obstiné de vous foutre de la tête des utlisateurs ouvertement.

J’ai déjà signalé il y a longtemps sous un rapport de bug précisément doccumenté que sous SMB2 la Freebox n’émet plus de NETBIOS (mais pas en SMB1)… l’absence de NETBIOS pose des soucis ponctuels sur certains logiciels, sous Windows comme sous Linux, même si en soi ce n’est pas un problème vital, mais ras le bol de galérer sur un truc qui pourrait être résolu en une vingtaine de minutes en revérifant vos scripts, juste qu’on refuse ouvertement de prendre en compte cette régression.

Les serveurs VPNs de la Freebox sont une bénédiction, un grand merci, c’est une solution majeure pour les globes trotteurs qui de l’étranger veulent se protéger de hotspots potentiellement malveillants.

La Rolls, un peu lente et ne fonctionnant que sur PC Windows ou Linux, c’est openVPN bridgé. IPv4 + IPv6 RAS

Si on veut connecter iOS, Android, Windows de façon native : IKEv2, IPv4 + IPv6 RAS

Vous avez choisi de proposer le protocole Wireguard, un nouveau protocole qui “monte” et semble-t-il un peu plus rapide qu’IKEv2 (mais je ne suis pas certains que ce soit onligatoirement plus sûr).

En l’état… c’est quasi inutilisable. L’IPv6 n’est pas implémenté.

Suite à des tests extérieurs, je me suis rendu compte que les serveurs VPNs qui ne fournissent pas d’adresse IPv6 posent souci :

- lenteurs sur certains sites
- certains sites sont totalement inacessibles. J’ai par exemple des petits jeu Android qui fonctionnent parfaitement chez moi en Wifi, mais ne fonctionnent pas en extérieur via VPN Wireguard, il faut que je passe par IKEv2

Concernant openVPN Routé… je n’ai pas la situation en tête, mais là aussi, il faut implémenter “si ce n’est pas déjà fait” l’IPv6
openVPN routé est la seule solution openVPN qui fonctionne sur Android et iOS (openVPN bridgé ne fonctionnera jamais sur iOS ou Android)

L’IPv6 est impératif désormais car beaucoup d’infrastructures ont basculé ces dernières années.
Un PC Windows sur une connexion “IPv4 only”, il a tendance à ramer…. les mises à jour, déjà lentes, deviennent très très lentes.

C’est sympa de donner le choix aux utilisateurs… mais juste un petit effort pour aller jusqu’au bout.

Je rouvre un nouveau ticket sur l’EXFAT car depuis 2019, ouverture du premier ticket il y a du nouveau

La manière traditionnelle d’accéder à l’exfat c’est FUSE bidule… c’est de la m..erde, je l’ai déjà aussi signalé par rapport à Fuse NTFS-3G (non NTFS ne consomme pas en soi plus de ressources qu’EXT4, c’est le framework fuse qui globalement est responsable de cette lenteur et cette débauche de ressources).

En 2019 (voir le ticket précédemment mentionné), Microsoft annonce avoir ouvert les specs d’exfat, pour une intégration tierce partie facilitée, dans la mesure où exfat est devenu de fait “la nouvelle norme” pour les appareils mobiles (APNs notamments).

J’ai été très mauvaise langue, car en 2019 je ne croyais pas trop en un développement rapide d’un module de noyau Linux

Et pourtant si… Samsung en 2020 a développé un module de noyau exfat intrinsèquement bien plus sûr et rapide qu’exfat fuse.
Ce module de noyau est désormais intégré de façon standard dans les derniers noyaux Linux, les distributions ont illico basculé leurs paramétrages par défaut pour utiliser le module de noyau plutôt que exfat fuse.

Sous linux, il y a juste à installer un paquet complémentaire “extfatprogs” destinés à fonctionner avec le module de noyau exfat (il fournit des outils de diagnostic et réparation) par opposition à exfat-utils qui lui est destiné à fonctionner avec exfat-fuse.

Selon mes informations… le module de noyau Exfat de Samsung a été intégré au noyau officiel depuis la version 5.7 (pour rappel le module de noyau NTFS3 de Paragon a lui été intégré depuis les versions de noyau 5.15)

Alors ma question est : qu’utilise actuellement la Freebox, exfat-fuse ou exfat Samsung ?

Si la réponse est : exfat-fuse, la seconde question sera : quand pourra-t-on espérer un basculement sur le module de noyau ?

Je conviens que pour NTFS3, la Freebox est peut-être encore sur une version de noyau trop ancienne (mais dans le fond je n’en sais rien), concernant exfat vu qu’on se contenterait d’un noyau 5.7… c’est quand même théoriquement nettement plus chaud, ou on a de quoi s’inquiéter si on nous annonce que la Freebox tourne toujours sur la version de noyau 2.6… question sécurité, ce ne serait pas “joli joli”.

Je possède une VM openSUSE Tumbleweed (Rolling Release) sur la Delta… je confirme que le noyau Linux AARCH64 implémente bien les modules de noyau NTFS3 et EXFAT (et il doit en aller de même pour ARM 32 bits qui à mon avis doit être l’architecture de la Freebox Revolution et de la Mini 4K)

Je rappelle que le basculement vers les modules de noyau en délaissant cette sa…loperie de fuse, engendrera un bond de performance gigantesque pour le NAS.

La logique voudrait qu’à l’avenir les gens utilisent EXFAT en priorité pour les disques USB car taillés pour les données mobiles (pas de fragmentation, pas besoin de journalisation, prise ne charge des fichiers supérieurs à 5 GO), parfaite transportabilité sur Windows comem Linux (en attendant un jour BSD).

Je rappelle que NTFS, un système de fichier à stratégie de fragmentation (donc volontaire, ce n’est pas un défaut de conception), conçu pour fonctionner avec une journalisation est en soi une hérésie sur un disque USB. NTFS a vocation à fonctionner sur des disques internes. A la limite EXT4 est plus intéressant (ext4 ne fragmente pas, et tout comme NTFS on peut désactiver la journalisation).

Avec le module de noyau exfat, la Freebox devrait être capable plus facilement et de façon transparente de réparer le système de fichier et le remonter, là où avec ext4-fuse et ntfs-3g, c’est plus compliqué, ça s’arrête fréquemment en eau de boudin avec à la clé des sueurs froides sur l’intégrité du disque.

J’ai mis sévérité à haute car messieurs les développeurs veuillez faire un effort… regardez le nombre de tickets ouverts relatant des erreurs de transmission de données, des interruptions de transferts sur disques USB, des pertes TOTALES de données. J’ai subi il y a longtemps une perte totale de données sur une SD formatté en NTFS, en passant en EXT4 j’ai fait disparaitre ce problème, mais cette SD n’est pas transportable sur un PC Windows (ce qui dans mon cas ne gêne pas plus que ça puisque je dispose de systèmes Linux)

L’intégrité des données sur les supports mobiles sur des format exogènes à Linux doit être votre priorité, la réputation de la Freebox s’améliorera de façon très importante face à des NAS comemerciaux qui eux peut-être implémentent déjà ces modules de noyau.

Vous n’avez plus aucune excuse, les modules de noyau existent… il faut simplement déjà qu’à minima on arrive progressivement à une version de kernel de 5.15 (et même au-dessus car le support de 5.15 va s’arrêter cette année je crois. Donc il faudrait basculer dans l’idéal sur le prochain kernel LTS, je ne sais pas lequel est désigné).

La DSI de l’Université de Toulouse est à la tête d’un petit projet de listes de blocage libre de droit.

Projet actif, les bases sont régulièrement mises à jour (une fois par semaine), et projet qui s’est quelque peu internationalisé avec différents contributeurs étrangers.
Cette liste de noms de domaines et d’adresses IP catégorisée par type de risque semble devenue au fil du temps la référence en terme de listes libres (évidemment Norton, Kaspersky, AVG… font ce travail depuis longtemps, mais il faut installer leur antivirus dans la version complète donc payante).

https://dsi.ut-capitole.fr/blacklists/

Il serait intéressant que Free se rapproche de la DSI de Toulouse pour discuter.
Peut-être serait-il opportun de faire un geste pour faire grandir encore ce projet en apportant la contribution de la DSI d’Illiad qui forcément est elle même confrontée à la gestion des risques.

D’après ce que j’ai compris, ces listes sont prévues pour fonctionner avec l’extension Squidguard du proxy Linux Squid qui est sans doute le proxy de référence des administrateurs.
Puis chacun paramètre son serveur Squid en fonction des listes qu’ils souhaitent bloquer

Je n’ai pas réussi à faire fonctionner SquidGuard sur mon openSUSE, le code semble cassé, ou je suis un bras cassé c’est aussi possible, donc j’ai fait un paramétrage grossier en forcant un réglage direct sous Squid, court circuitant Squidguard, autant dire que ça fonctionne de façon très peu optimale, mais étonnamment… ça marche pas si mal que ça

Comme je n’ai pas besoin de contrôle parental j’ai un fait un paramétrage inversé. Les sites jugés dangereux sont redirigés vers le proxy TOR pour masquer l’origine de la requête (d’autant que les Freenautes sont en IPv4 fixe), tous les sites et adresses IP n’appartenant à aucune liste passent par défaut par un proxy transparent, j’utilise ici privoxy.

J’ai écrit un script en Bourn Shell qui va chercher les mises à jour et les installent en stoppant / redémarrant automatiquement Squid
J’ai créé un service systemd et un timer pour décider du créneau horaire de requête avec création d’un aléa dans une plage horaire.

Mes navigateurs ont l’extension FoxyProxy Standard installée, les proxys sont paramétrés.
Je peux choisir pas de proxy, connexion Tor via la VM, connexion privoxy via la VM, connexion Squid… et mode automatique
Dans le mode automatique on établit une liste d’adresses qui ne doivent pas passer par le proxy (les adresses privatives), les autres adresses passent par défaut par le proxy squid

Tout cela tourne sous une VM Freebox OpenSuse Tumbleweed, pas de façon optimale car encore une fois ce sont des listes de type “squidguard”, mais ça fonctionne finalement pas si mal. J’ai fait des tests…. si je vais sur des sites porno je vois que squid passe bien par Tor (dans le cas d’un contrôle parental, on demande à squid de bloquer l’accès).

C’est une demande récurrente des parents qui veulent protéger simplement leurs enfants en bas âges, parents qui pour la plupart ne sont pas capables d’utiliser les antivirus avancés qui peuvent proposer des solutions intéressantes mais il n’est pas évident d’apprendre la logique des antivirus, de plus ces fonctions ne sont disponibles que dans les packs COMPLETS Internet protection donc forcément payants.

Si Free met en oeuvre cette solution sous sa Freebox, vous seriez les premiers je crois à faire cette démarche si attendue des parents.
Même si le filtrage ne sera jamais parfait, il résoudra au moins 80% des problèmes, et beaucoup de gens seront déjà contents.
D’ailleurs libre à Free d’implémenter ces listes de façon transparente. La Freebox peut fort bien par une régle de pare feu forcer la redirection vers le proxy Squid, ce qui évite d’avoir à paramétrer quoique ce soit sur les ordinateurs… ou on peut offrir les deux solutions à l’utlisateurs… soit accès proxy via port TCP 3128 (squid) soit forçage pour tout le mode au niveau de la box.

Au niveau de Windows ou Linux, on peut paramétrer un proxy HTTP de façon globale (donc pour tout l’ordinateur), solution adéquate pour les enfants, ou on peut passer par une extension du navigateur du type FoxyProxy

Vous gagneriez l’estime de pas mal de familles en France et peut être même d’organismes comme 50 millions de consommateurs. A côté de cela, le filtre anti pub que vous avez implémenté de longue date parait très peu légitime.

Je ne vais pas revenir là dessus je me suis exprimé sur le sujet récemment sur le fil “Youtube sponsor adblock” En revanche un contrôle parental c’est tout à fait légitime… c’est ce qui est attendu des parents. En plus si on pouvait finemment sélectionner les listes qu’on veut filtrer ce serait le top du top.

NB : l’avantage de ce projet est que c’est un projet piloté par un organisme français à but non lucratif. Il y a par ailleurs des projets communautaires (essentiellement tournés vers les anti pub) mais ces projets communautaires sont étrangers, on ne sait jamais trop ce qu’ils font qui travaille dessus avec quelle assiduité. Ici c’est l’Université de Toulouse qui apporte sa marque de neutralité et de probité histoire de dire que ce n’est pas la DSI de Toulouse qui va s’amuser à bannir Bouygues ou SFR pour aider Free dans son développement.

Les équipes de Free pourraient facilement les rencontrer et ces listes restent implémentables par tous les FAI français qui y mettent de la bonne volonté.

Sur des programmes communautaires étrangers, vous ne savez jamais ce que se passent réellement. Derrière un banal filtre anti pub vous pouvez très bien voir une multi nationale “X” soudoyer une personne du staff pour l’inciter à introduire un banissement de concurrents. Il y a eu beaucoup de grabuge autour de “WOT” qui eu fil du temps est devenu un projet commercial, et qui a reçu de l’argent de certaines entreprises afin d’améliorer leur notation. Ghostery est aussi devenu un projet commercial, d’ailleurs je l’ai abandonné, il n’arrêtait pas de me demander de se reloguer, il était incapable de retenir les login sur les mises à jour, aujourd’hui j’utilise uBlock ou Adguard

Bref… étudiez la question, voyez avec le service commercial si se cela ne pourrait pas constituer un argument complémentaire qui contenterait donc tout le monde chez Free, le temps passé dessus serait dont vite rentablisé.

Il s’agit à la fois d’une demande d’avolution à l’ocasion de la délcaration d’un bug.

Afin d’aider les utlisateurs à déboguer des problèmes de connectique réseau, il serait intéressant d’implémenter un renifleur de paquet visuel du type tshark ou nmap.

De l’interface Freebox OS on doit pouvoir lancer un scan sur l’interface de son choix WiFi / Ethernet et visualiser les flux.

Par exemple avec android 11 (?) / 12 / 13, j’ai un souci… la liste blanche du Wifi ne fonctionne plus.. ou disons que la connexion n’est plus autorisée comme auparavant.

C’est dû à un changement de design de Google depuis Android 12 (voire 11). Par défaut il semblerait que chaque fois que le telephone démarre il générère une adresse MAC aléatoire différente de l’adresse matérielle.

On peut créer un profile de connexion pour revenir à l’adresse MAC matérielle qui sera enregistrée dans la liste blanche de la Freebox, mais ça ne marche pas. Je soupçonne en fait qu’Android 12/13 utilisent l’adresse MAC aléatoire pour scanner les réseaux.

Il semblerait que la Freebox implémente un “white” listing hard en rejettant toute tentative de scan réseau d’adresses MAC non listées. Certains routeurs auraient un white listing moins “hard” en autorisant le scan de tous, mais en n’autorisant la connexion que pour les adresse white listées.

La présence d’un tel outil me permettrait de vérifier avec quelle adresse MAC android scanne les réseaux, ce qui me permettrait de white lister cette adresse MAC sans avoir à désactiver le White listing.

Je souligne que ça n’a rien à voir avec les réseaux cachés. Avant ou après android 11/12, la connexion sur réseaux à SSID caché ne pose aucun problème. Il s’agit bien d’un souci sur le white listing de la box qui bloque défnitivement toute connexion depuis android 12 (ou 11). Du reste le white listing / SSID caché ne pose pas souci sur les PC Windows / Linux, mais à priori ces systèmes démarrent avec l’adresse MAC matérielle, puis si nécessaire générère plus tard une adresse MAC modifiée si spécifié dans le profile de connexion.

Du moins c’est cela que je voudrais vérifier, et je suis d’ailleurs surpris que ce problème de White listing posant souci avec les verisions récentes d’Android n’ait pas été relévé plus tôt

Il s’agit d’un exemple parmi tant d’autre de l’utilité d’un renifleur de paquets qui nous permettrait en plus d’être un peu plus précis sur la déclararion des bugs.

La société Paragon connue pour développer des modules de systèmes de fichiers a décidé d’implémenter une version “light” de son module NTFS destiné à Linux sous licence GPL3.

La qualité du code a été jugée suffisamment bonne pour que ce module soit intégré directement dans le noyau Linux officiel à compter de la version 5.15 sous le nom de module NTFS3

Pour rappel, un module de noyau NTFS existait depuis longtemps sous Linux, mais il n’autorisait que la lecture.
Par conséquent, la solution fuse ntfs-3g est devenue la solution standard sur toutes les distributions Linux pour obtenir les droits de lecture / écriture sur systèmes ntfs.

On connait les limites de fuse ntfs-3g. c’est lent, très lent, très très très lent… et la fiabilité est discutable.
L’écriture fonctionne tant que l’on ne fait pas un usage intensif, mais dès que l’usage s’intensifie, il y a souvent des plantages avec toujours l’angoisse de peut-être corrompre de façon définitive le disque.

Les exemples d’utilisateurs Freebox qui ont connu des soucis variés avec des disques externes formattés en NTFS sont légion.
Il est aussi regrettable que dans l’interface Freebox, il n’y ait pas une alerte informant l’utilisateur que NTFS doit être utlisé avec prudence, ça n’est pas un système natif Linux

Néanmoins, le tout nouveau module de noyau NTFS3 apporte en partie une solution à ce problème.
Contrairement au module NTFS historique, il autorise la lecture / écriture et par rapport à ntfs-3g on est dans un autre monde.

10 fois plus rapide, bien plus fiable

https://docs.kernel.org/filesystems/ntfs3.html

On peut imaginer que la version du noyau de la Freebox ne doit pas être loin de 5.15, donc vous auriez tout avantage à implémenter le NTFS3 comme solution par défaut en remplacement de NTFS-3G

J’ai placé ce sujet en sévérité haute pour une raison assez simple…. BEAUCOUP TROP D’UTLISATEURS FREEBOX UTILISENT DES DISQUES NTFS CONNECTES A LA FREEBOX EN IGNORANT TOTALEMENT LES RISQUES, ce sont des kamikazes qui s’ignorent.

Encore dernièrement je répondais à un utilisateur d’Universfreebox qui bataillait avec des fichiers cachés impossibles à supprimer, fichiers système liés à fuse, restés sur le disque dur suite à une interruption brutale de transfert.

Encore une fois… fuse ntfs-3g C’EST DE LA MERDE !!!! , c’était une solution d’attente en attendant une implémentation libre de NTFS et en attendant un assouplissement de la position de Microsoft qui a peu plus ouvert sa documentation sur les specs de NTFS.

Dès lors qu’un module de noyau stable ET ADOUBE par Linus Torvarld lui-même est présent, on change URGEMMENT de fusil d’épaule et on implémente par défaut la solution NTFS3 si on a un minimum de respect pour ses utilisateurs.

A titre additionnel, vu que NTFS ne sera jamais un système natif à Linux, il faudrait ajouter une option de montage “lecture seule” qui pourrait alors s’appuyer sur les modules NTFS ou NTFS3, toujours en remplacement avantageux de fuse ntfs-3g, le gain de vitesse serait substantiel.

LIMITATIONS :

Comme indiqué sur le lien, NTFS3 n’implémente pas (encore) de journalisation qui le rendrait alors aussi robuste qu’un NTFS tournant sous Windows. Même si le lien laisse penser qu’une journalisation serait à l’étude (TODO list), il est peu probable qu’elle voit le jour car la version journalisée de NTFS3 sera sans doute encore longtemps réservée à la version commerciale de NTFS3, version commerciale qui existait depuis pas mal de temps.

On notera aussi qu’il serait question de développer une journalsation “jbd” (= sur la base d’un framework Linux), donc cette journalisation ne serait pas exploitable sur un ordinateur Windows si d’aventure le systèmes de fichier n’était pas “clean” au montage.

En basculant en SMBv2/v3 je me suis aperçu que certains de mes périphériques ne parvenaient plus à se connecter sur le NAS.
Typiquemen dans différentes applis Android qui ne reposent apparemment que sur le NETBIOS, et sont donc incapables d’utiliser les méncanismes d’UPnp, ou mDNS, il suffit de remplacer le nom NETBIOS par l’adresse IP, ce qui cantonne le problème à la stricte résolution du nom.

Windows, comme la plupart des applis graphiques Linux sont capables d’utiliser les mécanismes alternatifs, soit mDNS et SSDP, donc c’est globalement transparent sauf dans le cas spécifique de composants qui n’implémentent pas ces mécanismes alternatifs, comme certaines applis en ligne de commande sous Linux.

La solution de contournement est d’ajouter une entrée dans le fichier hosts, mais ce n’est pas possible sous Android.

Sous Linux, et sous réserve que nsswitch.conf soit bien paramétré, la commande suivante permet de résoudre l’adresse netbios, elle ne marche plus après la bascule SMBv2/3, mais marchait parfaitement sous SMBv1

getent hosts nom-netbios-freebox (KO)

En revanche la résolution via mDNS marche toujours avant et après

getent hosts nom-netbios-freebox.local (OK)

J’ai plusieurs fois rebooté le serveur notamment pour la toute dernière mise à jour, ça n’a rien résolu
Je viens de retester le mode SMBv1 only avec un nouveau reboot de la Freebox, et ça semble refonctionner comme avant après un petit délai le temps que la Box broadcaste le nom NETBIOS.

Donc le dameon “nmbd” responsable de la diffusion du nom NETBIOS de la Freebox, ne semble pas être lancé en mode SMBv2/3, mais se lance en mode SMBv1

Il est possible que certains soucis récents allégués sur l’UPnP liés à la non détection soudaine de certains périphériques après mise à jour de firmware soit en réalité un problème NETBIOS que personne n’a visiblement soulevé.

Il y a peut-être parallèlement des régressions sur l’UPnP, mais dans tous les cas, il y a un problème NETBIOS avéré, les tests effectués sous Linux semblent très clairs.