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

voila avec les ampoules ,les prises ,ect....connecté en wifi a serait bien de rajouter des icônes dans les périphériques réseaux pour ces nouveaux objets connecté

Bonjour,

Impossible d’activer le module DECT

Sur l’affichage de la freebox, dans les paramètres de téléphonie, j’ai le message “erreur”.
Et sur freebox OS, bien que le service téléphonie soit indiqué comme opérationnel, il est impossible d’activer la base DECT. A chaque fois j’obtiens le message d’erreur suivant : “erreur lors de la mise à jour de la configuration”.

Version du micrologiciel : 3.5.2

Adresse MAC : 00:24:D4:A0:53:4D

A noter qu’en même temps que l’apparition de ce bug, la freebox reste bloquée au moins 10 minutes en étape 9 avant l’affichage de l’heure.

J’ai bien entendu essayé de multiples reboot et fait sur les conseil de hotline, une réinitialisation du freebox server en paramètres d’usine, mais le problème persiste toujours !

Merci de votre aide

Rémy

Mes dect de marque Gigaset E310 préconisé par Free ont parfaitement fonctionné jusqu’au changement de ma box.
Depuis les communications avec mes contacts sont inaudibles sauf avec le 3244.Imaginez moi, entrain d’expliquer au gars de la plateforme assistance de free que mon téléphone est inaudible alors que le gars me dit que pour lui tout est très net !
La ou cela se complique c’est que depuis 6 mois si j’appelle le 3244 avec mes dect le 3244 passe bien et quand la bande son m’invite à taper choix 1 ou choix 2 les tonalités spécifiques a la touche 1 ou 2 n’ont aucun effet . Ceci vérifié ce jour par le technicien de chez free, avec lequel on a dissocie les dect de la box et reassocie, reset de box etc les téléphones ont été changés idem

Si il y a une marque de DECT qui supprime ce problème svp dites le moi j’achète.
Merci 2 ans à payer un service absent et ce n’est pas d’avoir essayé.

Je suis abonné et connecté à Free depuis le 16 avril, sur la plaque ZMD de Niort construite par Orange, à Aiffres (NRO/NRA=79003AIF), en fibre optique (il s’agit d’une migration depuis un accès Orange qui ne causait aucun problème avant pendant plus d’un an, qui n’avait jamais aucune perte).

Visiblement, vous y effectuez la collecte en IPv6 natif (et utilisez une encapsulation pour transporter IPv4).

Je constate que la FreeBox Revolution depuis le firmware 3.5.2 (qui a été installé dans la nuit de vendredi 25 avril à samedi 26 avril, en remplacement du firmware d’origine (sans doute, 3.5.0 mais j’ai oublié de le noter) a de grosses anomalies dans la gestion de bout en bout des MTU (pour TCP et UDP), y compris pour le segment réseau local.

Le protocole PMTUD ne fonctionne pas du tout (pourtant il est obligatoire pour IPv6), l’ajustement de taille des MTU ne se fait pas, la fragmentation IP a lieu, mais n’est pas conforme. De plus sur le segment IP6 WAN.

Le résultat est un débit catastrophique (vous avez sans doute déployé pour y remédier un tunnel de secours, permettant quand même de transporter les trames Ethernet non standards, mais qui ne passe pas par la route normale, mais est utilisé apparemment maintenant pour les utilisateurs de la plaque de Niort ayant une Freebox Revolution déjà migrée en 3.5.2, et transitant apparemment via des lignes optiques de SFR et OVH/Completel, mais ce tunnel est largement surchargé).

Cependant même ce tunnel (qui véhicule à la fois votre IPv6 et votre IPv4 est très instable et filtre des paquets ICMPv4 et surtout ICMPv6 indispensables). Je ne sais pas ce que fait la pile TCP/IP interne à ce firmware 3.5.2 de la Freebox Revolution, mais ça marche très mal, et n’importe quelle session TCP un peu trop longue finit par ralentir, à attendre des aquittements qui ne viennent pas ou qui ne viennent plus jamais car l’adaptation de MTU par PMTUD finit par dépasser des contraintes, et des fragments IP sont perdus, et après trop de demandes de renvois, les sessions TCP sont terminés brutalement, on obtient des fichiers tronqués en HTTP par exemple, sans aucun message d’erreur.

Il est impossible de télécharger un fichier de plus de 100 à 150 Mo en continu sur une seule session TCP (aussi bien via Internet que sur le LAN avec le fichier de test 1Go intégré à la Freebox disponible sur Freebox OS). Le seule moyen de transférer des gros fichiers sur Internet c’est par Torrent (sessions TCP courtes, c’est transmis par petits blocs de taille fixe), par exemple les Torrents d’image ISO de distributions Linux connues (par HTTP ça échoue à chaque fois). Impossible de télécharger une image ISO volumineuse par HTTP (par exemple une image de DVD d’installation de Windows) sans passer par l’outil de téléchargement de Microsoft (qui transmet par blocs avec vérifications). On voit cependant que les sessions Torrrent actives sont anormalement interrompues aussi (mais les Torrents peuvent retenter en utilisant d’autres connexions) (ceci affecte autant le client torrent intégré à la Freebox pour télécharger localement sur son disque dur qu’un client Torrent sur le réseau local).

Autre symptome similaire: la télé multiposte ne tient pas plus de 20 à 30 minutes sur une chaine HD: le streaming HTTP servi par la Freebox Player vers le réseau local via la Freebox server (utilisée comme switch) est lui aussi interrompu, les images se figent régulièrement et de plus en plus souvent. Et finalement la lecture s’interrompt brutalement (aussi bien avec le lecteur Flash proposé par Freebox OS, que par Windows Media Player ou avec VLC.

Tout indique que le non fonctionnement de PMTUD (ou le blocage inopiné des trames ICMPv4 ou ICMPv6 nécessaires pour signaler les MTU trop grosses ou permettre d’ajuster la MTU en TCP ou UDP ne fonctionne pas).

Le test de performance en ligne de Netflix dit la même chose en rapportant seulement le débit très faible, et là aussi les émissions sont interrompues inopinément (impossible de regarder un fluix pendant un heure, pas de flux HD disponible).

Même chose avec Youtube (diffusion en HTTP ou UDP multicast avec RTSP je ne sais pas trop): pas plus de 20 minutes en HD puis c’est coupé après de nombreus ralentissements.

Même chose avec les tests de performance de Speedtest.net: le trafic démarre vite pendant 1 ou 2 secondes puis baisse brutalement et ne cesse de chuter lentement. On voit nettement les pauses sans débit se multiplier, de plus en plus longues (ne recevant pas les statuts ICMP de “paquets trop gros”, le PMTUD pense qu’on peut toujours essayer d’augmenter la MTU, et après plusieurs essais, nécessitant de la fragmentation IP, ça finit par arriver, mais difficilement. Lorsque les fragments IP supplémentaires passent à une certaine taille, ils ne sont même plus signalés comme manquants, les tentatives de envois de trames TCP manquantes n’aboutissent plus car elles sont hors du cadre de la fenêtre TCP, et faute de réponse la session TCP tombe).

D’autres tests montrent qu’en UDP il y a un fort rejet de trames ou des trames perdues. Même chose avec des tests ICMP PING REQUEST/REPLY: on peut faire varier la longueur de payload, mais en fait cette payload est reçue tronquée (à 64 caractères par le destinataire qui la renvoie lui aussi tronquée dans l’écho) et les paquets ICMP indiquant des fragments manquants, ou des fragments IP trop gros ne sont jamais reçus.

La Freebox server sembnle bouloir expérimenter une nouvelle méthode non standard d’encapsulation d’IPv4 sur IPv6 sans couche d’adaptation (peut-être pour gagner un tout petit peu de bande passante ou optimiser la mémoire nécessaire dans vos routeurs et supporter plsu de client par vos routeurs avec une commutation un peu plus rapide, mais l’effet obtenu est totalement inverse: IPv6 dans sa version actuelle requiert absolument la prise en charge de PMTUD (alors que c’est facultatif en IPv4).

Ce protocole expérimental que vous avez déployé dans le firmware 3.5.2 de la Freebox Revolution ne fonctionne pas, n’est pas conforme. En zone ZMD où vous collectez le trafic par des opérateurs de transit, ce protocole est incompatible avec leurs équipements qui font des vérifications plus strictes (il est possible que vous ayez voulu aussi encapsuler ICMPv4 directement sur ICMPv6 sans couche d’adaptation et l’utiliser pour faire du routage spécifique par des options IP ajoutées aux trames IP, ou des options de suivi/Mdébogage, et que ces trames ICMP débordent leur MTU autorisées, la partie essentielle de la trame ICMP est perdue/tronquée, il ne reste que les options inutiles et les routeurs transitaires filtrent ces paquets invalides.

En urgence faute de pouvoir faire transiter votre trafic par le canal normal, il doit passer par un VPN établi au niveau Ethernet ou en dessous (comme PPP) pour faire cependant passer votre trafic Ethernet propriétaire et pas conforme. Mais ce VPN est surchargé. Il n’a pas la capacité de transporter les flux des milliers de vos clients sur la plaque de Niort, et même pas juste ceux équipés de Freebox Revolution et ce lien VPN est largement contraint par les règles de transit des autres opérateurs, imposant une règle d’équité des trafics dans les deux sens: règle 2 pour un pour les petites liaisons, amis plutôt 1,5 pour 1 ensuite pour le transit par les gros backbones.

Comme les clients Free sont très largement des particuliers et consomment surtout de la vidéo en streaming les flux sont surtout descendant avec un gros déséquilibre: le download de ces client est contraint par le débiut d’upload très faible lors de la lecture de vidéo en streaming, vous ne pouvez simplement pas acheminer des centaines de clients (ou plus) par un seul de ces VPN (hors vous y injectez aussi bien les flux des clients ADSL/VDSL que fibre: si l’essentiel de ces clients sont en zone quasi rurale ou très éloignés des DSLAMs, ce qui est le cas dans ma commune qui n’a de bon débits ADSL que dans une zone très limitée, le reste n’a du fait de leur atténuation pas plus de 5 ou 6 mégabit/s en download et ne sont même pas éligibles à la télé HD, ce sont ceux-là pourtant qui sont les premiers à utiliser la fibre, d’autant plus que depuis le fibrage quasi terminé de ma commune dans sa partie horizontale, des tas de lignes RTC ont été allongées et sont devenues inéligibles à l’ADSL, c’est le cas chez moi, le passage à la fibre est définitif, il n’y aura plus de retour en arrière, il n’y a plus les lignes les plus courtes nécessaires, les fourreaux ont moins de capacité car de la place a été faite pour la fibre: ne sont restés éligibles que les clients qui avaient déjà une ligne ADSL activée).

Ce phénomène se produit aussi dans la commune de Niort voisine, sur les autres lots de la ZMD, et tous les abonnés Free de la zone (y compris les premiers en test sur les 2 autres communes de Bessines et Charay en cours de fibrage sur la trentaine concernée par le démarrage rapide subventionné en partie par l’agglomération et le département).

Le système de collecte en ZMD (à Niort c’est en partie en AMII, mais des communes de l’agglomération sont hors périmètre de l’AMII et sont davantage subventionnées pour leur fibrage) et en Full IPv6 nécessite une implémentation impeccable des piles TCP/IP de vos Freebox. Ce n’est pas du tout le cas de la Freebox Revolution depuis la version 3.5.2: IPv6 ne fonctionne pas correctement et il n’y a aucun moyen facile de contourner le problème. Votre solution temporaire de routage d’urgence par un VPN ne peut pas absorber le trafic de la zone.

Résultat, panne générale depuis samedi matin, juste un léger mieux lundi dans la journée, à nouveau exécrable en début de soirée et toute la journée fériée du 1er mai (vos abonnés ADSL et fibre sont à domicile et consomment massivement de la vidéo), légéer mieux aujourd’hui en cours de journée, puis à nouveau exécrable à partir de 16h et toute la soirée jusque tard.

Votre VPN ne règle pas tout: le bogue de la Freebox Revolution 3.5.2 est toujours là dans sa partie “switch”. Et ça se voit. Un test de téléchargemetn depuis la Freebox vers le réseau local est tout autant affecté par le problème d’instabilité ou d’indétermination de la MTU qui finit par sortir des cadres et se désynchroniser entre émetteur et récepteur: assez vite TCP ne répond plus, les sessions tombent les unes après les autres après de nombreux échecs de demande de retransmission (qui en plus provoque de la surcharge supplémentaire sur votre réseau de collecte et la capacité de votre VPN de secours à l’absorber).

Bref je demande le retour de ma Freebox en version 3.5.0. Il va falloir revoir vos procédures de test et de montée en charge, et surtout ne plus déployer des versions beta directement chez vos clients non avisés (et en plus sans aucun canal de communication et sans même informer vos services de support client qui ne sont même pas habilités à remonter des tickets d’incidents et ferment les sujets: ils ne sont qu’abilités à tester le segment de la boucle locale, voient que la box est synchronisée et répond correctement à des tests trop simples)

Pourtant le simple test de transfert d’un fichier de 1Go suffit à démontrer le problème (et il pet être effectué directement dans la Freebox Server sanas même avoir à tester le réseau local ou le soupcçonner d’une mauvaise installation (le problème est identique si on débranche complètement la Freebox Server du réseau local, y compris en coupant le wifi, débranchat les cables Ethernet de vos Freeplug CPL, et celuui reliant le Freebox Server au Freebox player: on peut lancer le test en se connectant à distance sur la Freebox via Internet pour accéder à l’interface Freebox OS et on a le même résultat: les téléchargements de test depuis Internet vers le disque dur interne sont très très lents, souvent tronqués, ou corrompus quand on les valide par une somme de controle MD5 ou SHA1 si ces fichiers dépassent environ 100 Mo de taille.

Aucune session TCP ayant reçu déjà 100 Mo (ce qui arrive vite pour un flux TV HD en streaming sur HTTP/1.1) ne tient, que ce soit diffusé en IPv4 ou en IPv6, et votre tunnel de secours est surchargé durant toute la diffusion, seule le flux SD passe il manque des tas d’images, il y a beaucoup trop de demandes de retransmissions ou de resynchronisation du flux pour sauter directement des trames non reçues à temps, et sinon des transmissions en doublon à la lisière de ce timestramp de diffusion, ce qui accroit encore la charge.

Je pense que tous les abonnés en ZMD où vous avez commencé la migration de collecte en Full IPv6, et utilisant la Freebox Revolution avec ce firmware sont concernés (et visiblement cela concerne les communes nouvellement fibrées (mais déjà dégroupées depuis longtemps chez Free en ADSL puis VDSL) et particulièrement dans les zones urbaines les plus denses de ces ZMD où un NRO/NRA est occupé par plsu d’une centaine de clients: vos VPN de secours ne peuvent pas tenir la charge. Le sud-est de la ville de Niort et toute la commune d’Aiffres est impacté (et c’est encore plus visible poru les nouveaux clients qui ont les dernières box prééquipées pour IPv6 et chez qui tout allait bien avant que vous ne les passier en version 3.5.2)

Avec un combiné DECT de marque Logicom modèle Soly
Ce combiné a fonctionné depuis plusieurs années sans problème associé à la freebox, en ayant un téléphone filaire connecté sur le port phone en même temps. La dernière utilisation remonte à 3/4 semaines.
Ce jour, le combiné est toujours associé à la box. Si on appelle la ligne, il sonne, on peut décrocher et la communication audio est OK. Par contre, la numérotation ne fonctionne plus. Quand on décroche, le combiné prend la ligne, on a le retour audio de la tonalité mais les touches ne passent plus.
A travers l’interface web local de la box, on peut désassocier et réassocier le combiné, mais ça ne marche pas mieux. On peut également le faire sonner.
Ce même combiné, associé à sa base DECT logicom et cette base branchée au port phone de la box, fonctionne parfaitement... L’ensemble marche aussi connecté à une ligne analogique Orange.
le pb vient donc bien de la box.

Bonjour,

  Depuis plusieurs jours, j'observe la perte de synchronisation de mes téléphones avec la base DECT. Je les retrouve avec le message "cherche" sur l'écran. Depuis plusieurs années tout marchait sans problèmes et je n'ai pas fait aucune modification.

 Quand je rentre dans les paramètres de la Freebox dans DECT, je vois que le checkbox "Activer la base DECT" n'est plus coché (j'ai l'impression qu'il se décoché tout seul ...). Quand je le coche à nouveau et j'essai de valider par "OK" j'obtiens le message "ERROR: Impossible d'écrire la configuration" ou qqch comme ça. J'appui après "Appliquer" et la surprise, ça marche ... Après 1 minute les téléphones se synchronise avec la base et tout fonctionne à nouveau, mais pour combien de temps ?

Est-ce que Free peut corriger ce problème très embêtant pour les utilisateurs ?

Rafal

En utilisant le NAS de ma freebox Révolution depuis une Raspberry Pi, je me suis rendu compte d’une bizzarerie qui selon moi est un bug.

Il se trouve que les deux systèmes étant des linux, par défaut, les droits de fichier de la freebox sont transmis au client RPi (extension Unix de CIFS). Or j’ai observé 2 comportements différents:
1. Quand je mets la musique sur le NAS depuis un PC via SMB (partage Windows), tout se passe bien car fichiers et dossiers ont les droits Unix ‘777’.
2. Quand les fichiers sont copiés depuis un DD externe connecté à la Freebox via le FreeboxOS, on a des droits ‘700’, ce qui empêche à la RPi d’y accéder (vu qu’on récupère aussi l’utilisateur Freebox 4242).

J’imagine qu’une option du montage permettrait sans doute de désactiver l’utilisation des extension Unix de SMB/CIFS, mais ma distrib audio ne me laisse pas forcément toute latitude...

J’ai trouvé un hack pour modifier les droits de fichier du NAS (ce qui constitue sans doute une faille de sécurité), mais ça ressemble à un bug, non ? Pas de vrai différence au niveau des droits des médias que l’on passe par le LAN ou USB, à mon avis.

Stéphane

PS: Ma freebox est en 3.5.2 et le bug tracker ne connait même pas cette version...

Nous sommes de plus en plus harcelés sur nos lignes fixes. Bloctel et autre ne servent à rien.
Comme nous pouvons bloquer les numéros masqués, nous sommes désormais appelés par des numéros inexistants

C’est à dire qu’un numéro entrant est bien affiché mais si nous tentons de rappeler ce numéro, le numéro n’est pas attribué.

Serait il donc possible que la Freebox vérifie le numéro avant que l’appel arrive sur nos téléphones et rejette tout numéro qui n’existe réellement pas....

Bonjour,
depuis les dernières mises à jour, la présentation du N° de la base DECT intégrée ne fonctionne de nouveau plus. Mon DECT est un ensemble ALCATEL VERSATIS D300. La présentation fonctionnait avant. Cela dit au fil des mises à jours, depuis des années, la fonction disparaît et réapparaît souvent. On est habitué. Mais là, malgré les dernières màj, toujours rien.
Cordialement

Depuis mon raccordement chez FREE mes 2 Téléphones DECT n’on plus de micro sur les communications départs uniquement.
Sur les communications arrivées tout fonctionne normalement.
Le problème est uniquement avec des postes DECT, car avec un téléphone filaire raccordé à la freebox tout fonctionne bien mais la qualité est médiocre par rapport au téléphones qui fonctionnent avec la voie sur IP.
Mes téléphones sont des SAGEMCOM téléphone HD Allure DUO.
D’après Sagem le problème est connu de FREE et le dysfonctionnement n’existe qu’avec les FREEBOX.
Vous pouvez me joindre uniquement à partir de 14H00 au 06 48 49 63 38.

Cordialement

Lorsque la connexion est dysfonctionnelle, le serveur DNS de la freebox va répondre à toutes les requêtes en renvoyant l’adresse IP de la Freebox afin que celle-ci puisse afficher un message indiquant que l’accès internet n’est pas fonctionnel. Ce comportement bien qu’utile pour la majorité des gens peut être néfaste dans certaines circonstances et je souhaite donc avoir une option pour le désactiver.

Voici un cas où il me pose un problème. Comme ma ligne ADSL Free n’est pas très fiable, j’ai également une ligne ADSL OVH avec un boîtier Overthebox qui fait du VPN en utilisant les deux connections en TCP multi-path et qui monitore les connections pour que cela continue de fonctionner même si une des deux connections tombe.

Par défaut, le boîtier overthebox utilise les serveurs DNS renvoyés par le DHCP de la Freebox et du boitier ADSL OVH. Il utilise donc le serveur DNS de la freebox... y compris lorsque la connexion Free est tombée. Et dans cette situation là, le boîtier overthebox va obtenir des mauvaises réponses de la part de la Freebox. En plus, l’adresse IP renvoyée est l’adresse IP publique de la Freebox donc toutes les connections vont passer par la connexion internet Overthebox via OVH mais elles n’aboutiront évidemment jamais. Du coup tout semble bloqué...

Bonjour
Le module DECT se désactive après 10 minutes de fonctionnement.
Un reboot de la Freebox rend de nouveau disponible le module.
J’ai acheté un nouveau téléphone pensant que le problème venait de celui ci.
Pour constater : Ouvrir les informations Freebox Server/Player sur la TV, au bout de quelques minutes le module se désactive.
J’ai arrête tous les modes ECO sans succès.
Très pénalisant pour ceux qui sont néophytes, et qui ont toujours fait confiance au DECT embarqué.

Bonjour,
la suppression de périphérique réseau pour le wifi invité retourne une erreur “Erreur de la suppression de l’hôte:Pas d’hôte avec cet identifiant” et ne supprime pas l’appareil de la liste.

la modification du nom retourne une erreur 500 (c’est cassé!!)

freeboxOS 3.5.2 hw:r1 mini

Equipé de DECT Philips qui fonctionnaient parfaitement, depuis mi-février, les appels entrants se limitaient à 1 sonnerie puis impossibilité de récupérer l’appel. Les service technique Free n’a pas pu déceler l’origine de la panne et on a changé le Server. Depuis, j’ai découvert que la téléphonie fonctionne si ma base DECT est reliée en filaire au Server, mais la même panne se reproduit si je tente un fonctionnement DECT sans fil: 1 sonnerie et disparition de l’appel. En revanche le correspondant entend plusieurs sonneries et pens que nous sommes absents.

Bonjour,

J’avais commenté sur un autre ticket, mais il indiquait un dysfonctionnement complet du DECT - réglé suite à un remplacement - ce n’est pas le même problème (FS#22470).

Sur mon installation j’ai beaucoup de problèmes en réception - même après plusieurs reboots (il nous était arrivé - rarement - d’avoir des soucis de téléphone, qui étaient réglés par un reboot simple).
Le FW est le dernier stable : 3.5.2

Voici une description du problème rencontré - avec deux téléphone appairés (Philips, de base) :
* j’entends 2 sonneries sur mes combinés, puis plus rien.
* sur la box, on voit que la communication est en cours, et continue après l’arrêt des sonneries
* en testant depuis mon mobile, effectivement la communication continue continue, et on arrive à la boite vocale
* en tentant de prendre la ligne pendant ce temps où la communication continue, le combiné indique ligne occupé.

Si besoin : 14:0C:76:B2:44:F5

Merci.

La module DECT intégré à la freebox révolution R1 est HS.
La mise à jour en 3.5.2 ne résout pas le problème.

• Il serait apprécié que les sous dossiers présents dans un .torrent soient respectés.

A savoir, créer les sous dossiers décrits dans le .torrent lorsque le téléchargement d’un .torrent contenant des sous dossiers démarre.

Prendre en compte les sous-dossiers lorsqu’un fichier .torrent est ajouté pour être vérifié ou que le menu de vérification est appelé sur un torrent.

• Autre chose, je ne sais pas à quel point transmission a été modifié pour créer Freebox BitTorrent 0.2.0.0 mais si ce n’est que le peerid qui a été modifié, il serait apprécié de laisser la possibilité de présenter aux trackers le peerid du transmission d’origine via une option dans les paramètres.

Si la modification a été plus importante que le peerid, le fait de présenter le peerid du transmission sur lequel est basé Freebox BitTorrent 0.2.0.0 pourrait résulter sur un ban par le tracker.

La demande est en rapport avec le fait que certains trackers utilisent des whitelists et ne veulent pas ou ne peuvent pas qualifier Freebox BitTorrent 0.2.0.0 avant de l’ajouter à leur whitelist.

Bonjour,

Mes téléphones DECT reliés à ma Freebox ne fonctionnent plus. Les téléphone n’arrivent plus à se connecter à la base DECT.
L’activation du service DECT sur la console d’administration de la Freebox ne permet plus d’activer le DECT (http://mafreebox.freebox.fr/).

C’est le 3244 que j’ai appelé ce matin qui m’a conseillé de créer un incident sur ce site.

Ma ligne téléphonique fixe est donc hors d’usage.
C’est très génant !

Je vous remercie d’avance de votre support.

Geoffroy

Version Micrologiciel de ma Freebox : 3.5.2

Peripherique USB non reconnu suite au passage de 3.5.1 vers 3.5.2 sur freebox server mini:

Lexar uSD UHS2 RDR USB avec micro sd x1000 de 64GB
VID=05DC
PID=B055

Sur 3.5.1 le disque est reconnu, sur 3.5.2 le peripherique usb ne s’affiche plus.

Bonjour,
Il m’est impossible d’activer la base DECT. J’ai systématiquement une erreur “Erreur lors de la mise à jour de la configuration”.
Cela fonctionnait sans problème auparavant.

Firmware 3.5.2
Freebox Server (r1)

J’ai du rebrancher un téléphone derrière la Freebox en attendant une solution.

Merci d’avance pour une résolution rapide.

Bonjour,
depuis la mise à jour du 06 Mars du boitier server. impossible d’utiliser la seedbox. celle ci me retourne 2 erreurs :
-Erreur lors de la récupération des statistiques de téléchargement: Ce service n’est pas disponible actuellement
-Erreur lors de la récupération de la liste des fichiers: Ce service n’est pas disponible actuellement

De plus tout mes seed en cours on été supprimé de la liste et les paramètres de la seedbox se réinitialise systématiquement, pas d’enregistrement des modifications.

Bonjour,

Je rencontre toujours le problème du DECT c’est à dire HS sur ma ligne téléphonique même avec la mise à jour récente.

MAC 0024D4ABF704

Merci de faire le nécessaire.

Bonjour,
J’avais espoir que cette mise à jour résoudrait les problèmes remontés avec la tache  FS#22280  mais malheureusement ce n’est que partiel pour moi.
Connexion DETC et appel OK mais toujours pas d’affichage du N° entrant.
En jouant avec les paramètres DETC de Freebox OS soit j’ai la sonnerie et affichage “combiné 0” en sélectionnant sonnerie interne, soit j’ai l’affichage du N° mais le téléphone ne sonne pas en sélectionnant sonnerie externe ou tout autre paramètre de sonnerie autre que sonnerie interne. Le cochage ou non des autres options ne change rien.
Avant le passage à 3.5 cela fonctionnait impec.
Mon téléphone est un Philips M330
Ma freebox est une R1.
Merci d’avance pour votre aide.

bonsoir,

après mise à jour en 3.5.2 le DECT a repris un fonctionnement presque normal. Un problème subsiste cependant: sur appel entrant, le DECT sonne 2 fois et s’arrête alors que la ligne continue de sonner.

Merci

Bonjour depuis le passage à la version 3.5.2 plus de DECT
- Pas d’activation possible

Ca fonctionnait avant la mise à jour !

Freebox Server r1(remplacée récemment)
Adresse MAC : 00:24:D4:A7:F3:C0