Freebox V5 ADSL

Je suis actuellement en période de test Windows Vista, et suite à l’installation de ce dernier, lors de la mise à jour de Windows ou a une tentative d’accés au net, la freebox reboot.
Aprés recherche, j’ai désactiver le protocole IPV6 sur la carte réseau, et tout est redevenu normal.

Je dispose d’un chipset NForce2, et utilisé un port du switch de la freebox, avec le mode routeur activé.

IPv6 est acheminé dans le réseau Free via une encapsulation 6rd. Le MTU est donc de 1480 au lieu de 1500.
La FreeBox envoie bien ce MTU de 1480 dans ses annonces ICMPv6 de type router advertisement.
Donc les machines des clients, derrière leur FreeBox, annoncent un MSS adapté à ce MTU pour leurs connexions TCP sur IPv6.
Donc tout semble marcher, en TCP sur IPv6.

Mais si on fait autre chose que du TCP, ça ne marche plus.
En effet, si on reçoit un paquet non TCP, en IPv6 depuis une machine sur Internet nativement sur IPv6 (sans encapsulation 6rd ou autre type d’encapsulation), ce paquet ne peut pas arriver à la FreeBox et l’émetteur initial n’est pas informé qu’il doit ajuster le MTU pour cette destination routée par la FreeBox.

Voici pourquoi : l’interconnexion IPv6 de Free avec les autres systèmes autonomes constituant Internet n’envoie pas, ou filtre (ce qui revient au même), les paquets IPCMv6 de type “Packet Too Big” qui doivent pourtant être renvoyés lorsqu’un paquet IPv6 de 1500 octets entre dans le réseau IPv6 de Free. Donc l’algorithme PMTUD ne fonctionne pas et l’émetteur continuera à envoyer des paquets de 1500 octets qui n’arriveront jamais à la FreeBox destinataire.

Voici la preuve en analysant deux cas :

1er cas :
Si on lance des gros paquets ICMP depuis une machine chez un opérateur nativement sur IPv6 (cloud BrightBox dans cet exemple), vers une machine chez un opérateur qui encapsule IPv6 (www.tames.eu dans cet exemple), on reçoit alors correctement des ICMP “Packet Too Big” :

fenyo@brightbox# ping6 -s 1440 www.tames.eu PING www.tames.eu(2001:7b8:3f4::152) 1440 data bytes
From gw-524.ede-01.nl.sixxs.net icmp_seq=1 Packet too big: mtu=1280
From gw-524.ede-01.nl.sixxs.net icmp_seq=2 Packet too big: mtu=1280
From gw-524.ede-01.nl.sixxs.net icmp_seq=3 Packet too big: mtu=1280
[...]

2ième cas :
Mais si on fait la même chose depuis cette même machine nativement sur IPv6 (cloud BrightBox) vers une machine IPv6 derrière une FreeBox (fenyo.net), on ne reçoit pas les “Packet Too Big” qui devraient pourtant être envoyés par le routeur Free qui fait l’encapsulation 6rd vers la FreeBox (l’opérateur de www.tames.eu le fait, Free devrait aussi le faire, les conditions sont les mêmes) :

fenyo@brightbox# ping6 -s 1440 fenyo.net
PING fenyo.net(2a01:e35:8aae:bc60:222:15ff:fe3b:59a) 1440 data bytes
— fenyo.net ping statistics — 5 packets transmitted, 0 received, 100% packet loss, time 4030ms

Conclusion : IPv6 chez les clients de Free derrière une FreeBox :
- fonctionne pour TCP dans tous les cas ;
- mais ne fonctionne en UDP (ou autre protocole hors TCP) qu’avec des machines distantes chez des opérateurs qui font aussi de l’encapsulation pour apporter IPv6 au CPE (6rd ou autre). Il est impossible d’échanger de l’IPv6 autre que TCP avec des machines sur Internet nativement en IPv6 (sans encapsulation). C’est pourtant la majorité des machines sur IPv6, c’est donc un gros problème pour tous les protocoles hormis TCP : DNS sur UDP notamment.

J’avais le meme probleme sur la freebox v4, et sur la freebox d’un ami dans la meme ville,
Dans le menu ‘INFO FREEBOX ADSL’ sur la television, onglet RESEAU, les débits d’envoi et de réception sont inversés, (800ko/s en emission c’est un peu beaucoup je pense pour mes malheureux 1mb en upload), j’ai testé ça que en ethernet et c’est assez curieux..

Les informations de débit sur la partie “Réseau” de “Info Freebox ADSL” pour Ethernet et Switch sont inversées.

En effet, ma Freebox HD est connectée sur le port Ethernet et mon LAN est sur le port 1 du switch.

Donc, le trafic TV est vu sur le switch et le trafic LAN sur Ethernet.

Le proxy Wake on Lan de la freebox ne fonctionne pas lorsqu’une @IP est affectée à la DMZ.

Depuis la MAJ de la dernière version du firmware du boitier ADSL, il est possible de brancher une imprimante sur le port USB (habituellement utilisé pour relier la fbx à l’ordi en USB). L’imprimante se trouve alors partagée sur le réseau local (sous windows : ajouter une imprimante locale sur le port “tcp/ip” à l’adresse mafreebox.freebox/fr (port 9100)).

Or la dernière page n’est jamais ejecté. Testé avec deux ordi différent (XP et 2000) : meme en faisant le test d’impression windows (”imprimer une page de test”), la page ne sort pas et reste coincé.
Testé avec une EPSON STYLUS D92, dernier driver. Quand l’imprimante est directement connecté à l’ordi, avec les mêmes drivers, pas de problème d’ejection de la derniere page.
Le serveur d’impression de la freebox ne bouffe t il pas la derniere commande ?

j’ai installé une Canon PIXMA IP5000 sur le port USB de la FreeBox
ca marche, feuille recto verso
le seul bug pour l’instant, l’imprimante ne répond pas (pas de status)
comme pas exemple plus de papier, cartouche vide..., capot fermé, tiroir DVD ouvert....
est-ce normal?
——–nota————– le status de l’imprimante est correct si l’imprimante est branchée sur Ordi principal, pour un demande d’impression d’un autre Ordi...

Salutations

vec le firmware Free ADSL 1.3.0 et l’annonce d’une possibilité d’impression via son port USB, tout le monde, d’après les divers forums, rencontre le problème suivant à savoir que le flux d’impression n’est pas terminé et que la dernière page reste bloquée à mi-hauteur. Il faut alors envoyer une nouvelle page nulle (echo |lpr sous linux) pour que le flux de la dernière impression soit transmis à l’imprimante USB et que la dernière page sorte. Bien entendu, la page vide est elle-même bloquée et il faut annuler l’impression manuellement sur l’imprimante. Pour les OS (quelqu’ils soient, Windows ou Linux), l’impression apparaît comme terminée. C’est donc bien au sein de l’OS de la freebox ADSL que le flux n’est pas transmis en entier. Une sorte de fflush qui manque au programme pour vider le buffer de sortie.

Je n’ai pas trouvé de bug relatif à cette anomalie et c’est pourquoi je vous fais ce courrier.
Sur les news, une personne a dit que le problème était résolu avec le firmware 1.3.1 ADSL qui était en test. Mais je ne sais pas où trouver ce nouveau firmware ni si cette anomalie est résolue.

Cordialement,

PS: J’avais mal aiguillé ce bug vers Freebox HD et je la redirige vers Freebox ADSL

Avec le firmware Free ADSL 1.3.0 et l’annonce d’une possibilité d’impression via son port USB, tout le monde, d’après les divers forums, rencontre le problème suivant à savoir que le flux d’impression n’est pas terminé et que la dernière page reste bloquée à mi-hauteur. Il faut alors envoyer une nouvelle page nulle (echo |lpr sous linux) pour que le flux de la dernière impression soit transmis à l’imprimante USB et que la dernière page sorte. Bien entendu, la page vide est elle-même bloquée et il faut annuler l’impression manuellement sur l’imprimante. Pour les OS (quelqu’ils soient, Windows ou Linux), l’impression apparaît comme terminée. C’est donc bien au sein de l’OS de la freebox ADSL que le flux n’est pas transmis en entier. Une sorte de fflush qui manque au programme pour vider le buffer de sortie.

Je n’ai pas trouvé de bug relatif à cette anomalie et c’est pourquoi je vous fais ce courrier.
Sur les news, une personne a dit que le problème était résolu avec le firmware 1.3.1 ADSL qui était en test. Mais je ne sais pas où trouver ce nouveau firmware ni si cette anomalie est résolue.

Cordialement,

Bonjour,
je vous explique ce que je pense etre un probleme majeur:
lorsque l’on coupe le wifi et que l’on coupe aussi le Freephonie en utilisant l’interface web d’administration...
les reseaux wifi(qui ne broadcast pas tous leurs ssid) sont toujours present.

et donc selon mes mesures... ils sont au nombre de 3 ou 4 selon les moments...
je suppose qu’il y a: le MIMO pour la TV (alors que je l’ai relie en Ethernet!), le reseau Wifi de base, le Freephonie et un autre inconnu...

autrement dit, la module Wifi present dans la FreeboxV5 continue d’emettre en permance... meme lorsque je ne le desire pas !!!

Pourrait-on planifier une evolution pour pouvoir couper definitivement ce module Wifi ?
ou alors le seule solution pour moi serait de demonter la Freebox ? (je m’y refuse vu que je pense que ce evolution sera possible
tres bientot...)
Merci d’avance pour votre aide.
sebastien

Bonjour,
après 48h d’absence, donc sans aucune modification matérielle ou de configuration, ma freebox ne distribue plus d’ip à mon réseau local, alors que le réseau wifi reste fonctionnel.
Tests effectués :
- plusieurs câbles ethernet testés
- chacun des 4 ports de la box testés
- 4 machines branchées en direct sur les ports ethernet (1 pc windows 7, 1 pc unbuntu 18.06, 1 laptop windows 7 , 1 laptop ubuntu 18.06)
- pour chaque machine, configuration auto et configuration manuelle
- hard reboot de la freebox
- divers flushs en ligne de commande pour les pc windows
- appel de l’assistance technique qui ne détecte aucune anomalie, voit les branchements sur les ports ethernet, a procédé au reset usine de la freebox, sans succés

24h avant mon absence, il me semble que la freebox avait procédé (à priori, pas de certitude) à une MAJ (lignes horizontales montantes et descendantes), mais l’ensemble de mon réseau était fonctionnel avant mon départ.

Je ne sais plus quelle piste explorer, une idée quelqu’un ?
Merci par avance.

Lorsque je reçois un appel téléphonique, très souvent je ne peux pas répondre : quand je décroche, je n’entends personne. Comme j’ai un téléphone avec présentation du numéro, je rappelle la personne, mais bon ce n’est pas normal.
Tout fonctionnait normalement avec le même téléphone et ma freebox V4.
Je précise (mais ça n’a sans doute rien à voir) que j’ai un message téléphonique que je ne supprime pas et qui reste dans ma boîte vocale.

Malgrès plusieurs scan TNT je n’arrive plus à avoir Canal+ en clair mais il marche dans l’univers Freebox(sans abonnement à Canal+)

Les message de NOTIFY que la Frebox ADSL envoie toutes les minutes pour signaler que son IGD est toujours présent n’ont pas de header HOST ; certains control points UPnP ne voient plus le IGD 4 minutes après la réponse au message M-SEARCH initial ; tous les programmes Java qui utilisent le UPnP CyberLink sont dans ce cas (le plus utilisé).

NOTIFY * HTTP/1.0
SERVER: UPnP/1.0 fbxigdd/1.0
LOCATION: http://192.168.0.254:5678/desc/root CACHE-CONTROL: max-age=180
NT: upnp:rootdevice
NTS: ssdp:alive
USN: uuid:73616d61-3a65-7374-650a-0006cbb69d40::upnp:rootdevice

Ce header est required dans la “UPnP™ Device Architecture version 1.0” (http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf, page 15) pour avoir des messages compatibles HTTPMU, HTTP over multicast UDP.

Solution :

 ajouter une ligne "HOST: 239.255.255.250:1900" aux messages SSDP, pour qu'ils soient conformes à la spécification UPnP.