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  asc Système d'exploitation État Résumé
1663021/03/2015ÉvolutionDiversTousNouveauEteindre les LED des RJ45 Description de la tâche

Bonjour,
Sur la v5, il y avait une option pour éteindre les diodes en façade indiquant la connexion réseau. Il était possible de désactiver l’affichage de ces diodes.

Sur la freebox mini (server et mini 4k), il y a les diodes indiquant l’état d’une connexion derrière les box (vert et orange). Le problème c’est qu’elles brillent beaucoup (c’est neuf) et les reflets sur le mur se voient bien dans une ambiance sombre.
Ce serait bien d’avoir une option pour:
- soit diminuer la luminosité
- soit les éteindre complètements
- ou alors n’avoir qu’un flash lorsqu’il y a du trafic (éteins tout le temps, sauf en cas de data)

 16928 31/03/2015AnomalieDSLTousFermée [IPv6] Problème de fragmentation ou problème de MTU  Description de la tâche

Bonjour,
Ayant activé l’IPv6 avec une freebox server (+ mini 4k) en VDSL, j’ai remarqué qu’il y a un souci de fragmentation qui fait que la découverte de la MTU peut se retrouver faussé.
Dans mon réseau tout ethernet en IPv6, j’arrive sans problème à avoir un ping non fragmenté avec une MTU de 1500.
En gros:

ping6  -c 1 -M do -s 1452 2a01:xx:xx:xxd0:mes_machines

Ça passe sans problème.

ping6  -c 1 -M do -s 1453 2a01:xx:xx:xxd0:mes_machines

Je reçois bien:

From 2a01:xx:xx:xxd0:mes_machines icmp_seq=1 Packet too big: mtu=1500

Tout va bien en local.
Avec wireshark, je n’ai aucun problème: 1 paquet envoyé = 1 paquet reçu, MTU = 1500.

Par contre, je fais pareil avec la freebox server:

ping6  -c 1 -M do -s 1452 2a01:xx:xx:xxd0::1

Aucun problème n’est remonté.
Par contre, avec wireshark je vois une réponse en 2 paquets fragmentés.

En investiguant d’avantage, j’ai remarqué que le ping fonctionne bien avec une MTU de 1480:

ping6  -c 1 -M do -s 1432 2a01:xx:xx:xxd0::1

Au dela, j’ai 2 fragments.

De même, j’ai l’impression que dans l’autre sens quand un PC extérieur accède à l’intérieur du réseau, la découverte de la MTU ne fonctionne pas correctement et cela rend la connexion inopérante (pas de réponse du genre “MTU too big”). Par contre je n’ai de log dans ce sens.

Du coup, je ne sais pas si le problème est imputable à la freebox, au routage, à une encapsulation de l’IPv6 ou à autre chose, mais du coup j’ai des problèmes MTU que j’ai résolu en déléguant une partie du /61 derrière un routeur, et en forçant le routeur à avoir une MTU de 1480 côté WAN relié à la freebox.

- Ma freebox est une mini freebox server (avec mini 4k) avec firmware 3.1.1
- J’ai une connexion VDSL2 - si jamais il y a de l’encapsulation qui ne fonctionne pas bien
- Tout mes tests sont en ethernet filaire.
- La freebox est configurée en mode routeur + délégation d’un sous réseau IPv6 derrière un autre routeur

J’ai refait les mêmes tests en IPv4. Je constate bien dans ce cas là qu’il n’y a pas de fragmentation aussi bien sur le réseau interne que sur les serveurs externes (IP en x.x.x.254, voir google) jusqu’à une MTU de 1500. Donc si encapsulation il y a, cela ne concerne pas l’IPv4.

Pour information, je n’ai presque plus rien derrière la freebox (sauf pour test). Je préfère utiliser mon routeur pour l’IPv6 tant que le  bug 4110  http://dev.freebox.fr/bugs/task/4110 n’est pas corrigé (firewall en IPv6). Cette configuration limite également le MTU du l’IPv4, ce que je trouve bien dommage.

 19903 08/03/2016AnomalieLANTousFermée [IPv6] Fragmentation non signalé lors d'accès à la free ... Description de la tâche

Bonjour,

Je suis en VDSL avec une encapsulation 6rd pour l’IPv6. J’utilise mon propre routeur configuré en dual-stack pour gérer l’IPv6.
Donc pour accéder à internet en IPv6, la freebox retourne une MTU de 1480. Pour accéder au réseau local en IPv6, la MTU donnée par le routeur est 1500.
Le routeur redistribuant les paquets “ICMP6 too big” aux clients, ils n’ont aucun problème pour accéder au net avec la bonne MTU.

Le seul “souci” est dans le lien en direct à la freebox en IPv6 (interface web, test débit local, NAS, etc.) avec un protocole autre que TCP (UDP, ICMP).
En effet, les clients peuvent y accéder avec une MTU de 1500 et à priori la freebox ne retourne à aucun moment de paquet “ICMP6 too big”, même si elle fragmente la réponse.
Autant en TCP le MSS clamping permet de ne pas avoir de problème, autant en ICMP (et UDP aussi je suppose) il peut y avoir des petits problèmes de fragmentation.
Capture du premier paquet d’un ping sur la freebox d’un paquet ICMP de 1433 octets (1 octet de plus que permet une MTU de 1480):

$ sudo tcpdump -nai eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:48.212663 IP6 2a01:xx::xx > fd0f:ee:b0::1: ICMP6, echo request, seq 1, length 1441
16:50:48.213012 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 1, length 1432
16:50:48.213070 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (1432|9)

La même chose sur un serveur IPv6 supportant la fragmentation:

$ sudo tcpdump -nai eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:26:21.358569 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: ICMP6, echo request, seq 1, length 1441
**17:26:21.358929 IP6 2a01:<freebox>::1 > 2a01:xx::xx: ICMP6, packet too big, mtu 1480, length 1240**
17:26:22.360669 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (0|1432) ICMP6, echo request, seq 2, length 1432
17:26:22.360764 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (1432|9)
17:26:22.390095 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 2, length 1432
17:26:22.390166 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (1432|9)
17:26:23.362660 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (0|1432) ICMP6, echo request, seq 3, length 1432
17:26:23.362758 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (1432|9)
17:26:23.391572 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 3, length 1432
17:26:23.391637 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (1432|9)

En gros:
- la box répond bien à un paquet lui étant destiné, même si le paquet est trop grand par rapport à sa MTU (1480)
- la réponse est fragmentée (soit !)
- ce qui en soit n’est pas choquant, la MTU de l’interface en IPv6 devant être forcé à 1480 je suppose par son ravd interne
- mais à AUCUN moment je n’ai eu un ICMP too big ⇒ ça ce n’est pas normal
Le même tcpdump sur ping trop grand vers un serveur internet qui l’accepte (www.subnetonline.com) montre bien que la freebox retourne un “ICMP6, packet too big”, mais quelle fragmente bien le request car je vois également les fragments de reply arriver.
A mon avis, quand on accède à une IPv6 de la Freebox avec un paquet trop grand:
- soit la freebox doit retourner un ICMP too big en plus de ses fragments
- soit elle doit être capable de répondre sans fragmenter
Voila, c’est à mon avis un petit bug qui va être vite corrigé.

1951922/01/2016ÉvolutionNAT (redirections, DMZ)TousNouveau[NAT] Ajouter la possibilité de rediriger d'autres prot... Description de la tâche

Bonjour,

J’ai constaté qu’il n’est pas possible de créer un règle pour rediriger des paquets provenant du WAN vers un client particulier du LAN autres que pour les protocoles TCP et UDP.

J’aimerais pouvoir par exemple pouvoir rediriger les paquets ESP (pour IPSec) provenants d’une IP particulière (ou de toutes les IP) vers un PC client du LAN.

Quant dans “Redirection de port”, j’essaye de mettre autre chose que TCP ou UDP dans “Protocole”, j’ai le message “protocole invalide”.
J’aimerais par exemple pouvoir mettre “50” (pour un protocol code particulier) ou “50-55” (pour un range) ou “50,51,53” (pour une liste de protocole code) ou “esp” (pour un protocole connu). Dans ces cas là, les numéro de ports deviennent facultatifs.

Attention: ce bug ne concerne pas IPSec qui est ici utilisé en exemple (je n’ai pas de problème particulier avec IPSec merci, c’est juste le premier exemple que j’ai trouvé qui n’utilise pas que TCP et UDP).

 22865 09/10/2018ÉvolutionServeur VPNTousFermée [Evolution] Intégration d'un client/serveur wireguard V ... Description de la tâche

Bonjour,
Pour avoir testé wireguard, il s’agit d’un nouveau client/serveur VPN basé sur la simplicité d’utilisation et un nouvel algorithme de chiffrement.
Plus d’information ici:
https://www.wireguard.com/

Il serait bien d’intégrer un client et un serveur wireguard dans une nouvelle révision de l’OS.
Cela se fait simplement sur linux, et cela crée une nouvelle interface (wg0 par défaut) dans lequel vous passez le tunnel que vous voulez. Le tunnel passe en UDP sur un port (à configurer). Le chiffrement est plutôt performant et permet d’atteindre de bon débit bien que cela soit fait en soft.

A mon avis l’intégration sera simple et rapide.

2063206/09/2016AnomalieUSBTousNouveauPerte du disque USB lors d'un reboot s'il est en veille Description de la tâche

Bonjour,
J’ai un freebox server associé à une mini4k. Donc sans disque interne.

J’y ai connecté un disque dur en USB. J’ai activé la mise en veille au bout de 10 minutes.
Ce que je constate, c’est que:
- si je redémarre le server à distance via le compagnon ou via l’interface embarqué
- que le disque dur connecté en USB est en veille à ce moment là
ALORS:
- le disque dur n’est plus énuméré

Ce qui est plutôt très gênant si on a une mini4k (plus d’enregistrement possible, plus de synchronisation de photos, etc.).

Un contournement consiste à redémarrer 2 fois de suite le server, car le premier démarrage fait quitter la veille au disque dur (surement lié au bug suivant http://dev.freebox.fr/bugs/task/19056 ).

Tâches 1 - 6 sur 6 Page 1 sur 1

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche