Tous les projets

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.

Description:
- une souris appairé en bluetooth (en fait un clavier-souris K810, mais cela doit probablement être la même avec une autre souris)
- bouger la souris

Sur la version précédente, un curseur apparaissait tant que la souris bougeait et disparaissait après quelques seconde.
Sur la bêta, plus de curseur ! Par contre le déplacement de la souris provoque bien des mouvements (par exemple un sélecteur qui s’illumine), tout comme le clique sur un sélecteur.
Conclusion, la souris existe mais le curseur permettant de le voir ne s’affiche plus.

Description:
- depuis l’application TV se mettre sur une chaine (configuration courante: IPTV en HD)
- depuis cette application regarder un enregistrement (OK puis choisir un enregistrement)
- quitter l’enregistrement en appuyant sur le bouton “retour” (flèche en bas à gauche de la croix)
Systématiquement l’application revient sur la chaine mais affiche un écran noir.
Un changement de chaine résous ce souci.

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é.

Hello,

J’ai repéré ce souci chez moi avec anExplorer et MxPlayer gratuit, et le souci semble concerner au moins quelques personnes - voir le forum UniversFb ici http://forum.universfreebox.com/viewtopic.php?t=54552 .
En fait, dés que j’ouvre une application gratuite, quand la pub doit s’afficher (tout le temps avec anExplorer, ou quand on met en pause une vidéo avec mxPlayer) elle s’affiche bien, puis au bout d’une à 2 minutes quand la pub doit changer, et bien l’application plante complètement et je doit la relancer de nouveau.

Alors c’est un peu (beaucoup) gênant car des appli avec de la pub il y en a pas mal chez android.

Ma solution pour le moment c’est d’éviter les applications affichant de la pub ou alors d’aller très vite dans leur configuration.

Je conseil aussi fortement d’utiliser ES Explorateur au lieu d’anExplorer dont l’apk qui est gratuit sans afficher de pub, et dont l’apk est disponible sur le site du créateur eStrong (même si la gratuité doit cacher un truc, mais quoi ?).

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.

Bonjour,

Soit disant il n’y a qu’un seul tuner TNT, il n’est pas possible de faire du timeshifting sur la TNT.
Techniquement, le flus de donnée soit ressembler à ça:

Tuner TNT —flux numérique 0/1—> SoC –0/1–> GPU –0/1–> TV

Etant donné qu’il est possible d’enregistrer les chaînes de la TNT, on doit avoir le schéma suivant:

Tuner TNT —flux numérique 0/1—> Soc –0/1–> Server —-0/1—> disque dur

Qu’est ce qui empêcherait de faire fonctionner le timeshift en utilisant le flux suivant:

Tuner TNT —flux numérique 0/1—> SoC –0/1–> Server –0/1–> disque dur –0/1–> Server –0/1–> SoC–> GPU –0/1–> TV

En gros, l’idée serait de basculer le flux numérique de la TNT de l’affichage vers le server, et afficher le flux du server.
Cela ferait doubler le flux réseau, mais si le réseau est gigabit cela sera complètement gérable. Quitte à faire un test réseau au démarrage et à afficher une pop-up disant que le timeshift TNT ne fonctionne que si le player est relié en ethernet Gb sur le server.

Bonjour,

Je viens de passer de la freebox HD à la mini 4K.
J’avais déjà des problèmes de coupures de son sur ma freebox HD avec ma TV (coupures de quelques secondes de temps en temps). La solution avec la freebox HD étant de passer la sortie HDMI en 720p et fini les coupures (cf bug http://dev.freebox.fr/bugs/task/3436 ). C’est pour planter le décors, comme quoi j’avais déjà des soucis avec l’HDMI et ma TV.

Je pensais que ce problème allait disparaitre avec la mini 4K.
Hélas, j’ai remarqué que sur la plupart des chaines HD j’ai une image qui saccade légèrement. Bon, c’est supportable.

Mais ce qui est particulièrement criant, c’est sur NRJ 12 en HD ou là j’ai carrément le stream audio qui est hachuré avec la vidéo. Autant la vidéo ça passe, autant là l’audio est tellement hachuré que même si c’est compréhensible ça devient insupportable.
Ma solution pour l’instant, c’est de passer la chaine en définition standard.

Mon environnement,
- fbx mini 4k relié en ethernet au serveur.
- pas de problème de débit (VDSL, Fastpath, 1100m, 24M/3M).
- chaines en IPTV ou le problème est visible: TF1 HD, F2-4 HD, M6 HD, etc. Criant sur NRJ12 HD
- TV: Sony 40 WE5 (modèle de 2008/2009)
- j’utilise un câble HDMI standard à 2€ acheté chez free il y a longtemps, et pas le câble fourni

Pour information, je n’ai pas testé en TNT car je n’aime pas ne pas pouvoir mettre la chaine en timeshift alors j’ai désactivé la TNT.