Freebox V5 ADSL

Après l’envoi d’un courrier fax, pour qu’il est une valeur juridique, il faut produire un récépissé d’envoi de fax détaillé avec les coordonnées émetteur/destinataire, date d’envoi, nombre de pages transmises, accusé destinataire, photocopie réduite de la première page ou mieux des deux premières pages.

Le routeur annonce

LOCATION: http://192.168.0.254:5678/desc/root

mais, il n’y a pas de serveur HTTP sur ce port, pour distribuer les advertisements.

depuis la 1.5.6

Même “GUPnP Universal Control Point” ne signale pas le IGD ; alors qu’il signale bien MediaTomb.

Depuis le début je ne comprenais pas pourquoi les control point UPnP n’affichaient pas bien le IGD de la Freebox ; et j’en ai essayé quelques uns.

En fait, tous les devices du IGD ont le même UDN, Unique Device Name, que ce soit le root device ou bien les embedded devices.

La doc n’est pas très clair à ce sujet, elle dit de mettre uid:UUID, sans vraiment préciser si tout ces UDN doivent être identiques ou différents ; tout ce que j’ai pu trouver sur le sujet, c’est que d’autres IGD ont des UDN différents pour chacun de leurs embedded devices.

Quelques exemples :

http://www.securiteam.com/securityreviews/6K00L20EUE.html http://svn.dd-wrt.com:8000/dd-wrt/browser/src/router/upnp/xml/InternetGatewayDevice/InternetGatewayDevice.xml http://forum.utorrent.com/viewtopic.php?id=10373 http://pidgin.im/pipermail/devel/2008-May/005823.html

Mis à part ceci, qui est le plus important, j’ai remarqué trois non conformités au protocole SSDP implémenté dans le IGD de la Freebox.

Par ordre d’importance :

1) il envoie des “NOTIFY * HTTP/1.0” ; alors que il devrait envoyer HTTP/1.1, conformément à UPnP/1.0 ;

      il pourrait être ignoré par des control points pointilleux.

2) il envoie des headers “CACHE-CONTROL: max-age=180” ; alors que pour UPnP/1.0 max-age doit être au minimum de 1800 secondes ;

      et il envoie ses NOTIFY toutes les minutes et quelques au lieu de toutes les 15 minutes environ.

3) il envoie des headers “SERVER: UPnP/1.0 fbxigdd/1.0” qui ne commencent pas avec OS_name/OS_version ;

      là, je ne vois pas trop ce que ça pourrait gêner, à part des control points pointilleux².

Bonjour,
Suite à la màj 1.1.3, il n’y a plus l’erreur 42 à la màj du freephone blanc.
Mais aprés chargement des màj et redémarrage du téléphone, celui-ci est toujours inopérant...
Le bargraph du signal WIFI est à zéro il y a les messages “No Network” et “Pas de service” affichés.
Que faire ?
Merci d’avance de votre prise en compte.
Dans l’attente de vos informations quant à ce problème, recevez mes salutations les meilleures

Bonjour,

La protection à mafreebox.freebox.fr est trés mal sécurisée.
A l’arrivée dans l’écran de saisie du mot de passe, n’importe qui
peut le changer à la maison en cliquant sur “générer un nouveau mot de
passe” si tant est qu’il voit la Freebox ... Il peut alors à son gré
changer les paramètres, enlever le contrôle parentale, etc ... Ce mot de passe
ne sert dons pas à grand chose en l’état ...
Merci de faire un système du type “J’ai oublié mon mot de passe” où
celui-ci sera par exemple envoyé par mail, etc ...

Bonjour

J’ai une freebox V5 Only NDI.

Le Proxy Wake On Lan ne semble pas fonctionner.
Le paquet passe très bien en local mais par contre, malgré que l’option Proxy WOL soit coché, le paquet ne passe pas lorsqu’il arrive pas internet.

Merci

ma freebox se redémarre souvent

Bonjour
Lors de la définition de ma clé WPA, je génère celle-ci avec un générateur aléatoire ( http://www.kurtm.net/wpa-pskgen/ ) qui puise les caractères utilisés dans la liste des 95 caractères ascii imprimables conforme à la spécification WPA. Je n’ai aucun problème avec ce genre de clés sur des routeurs ddwrt (sauf que sur certaines version du firmware, il faut masquer les caractères pour contourner un contrôle abusivement restrictif dans le GUI).
Il faudrait au moins indiquer dans la console de gestion quels sont les exclusions de caractères autorisés parmi ceux de la norme. Dans l’idéal tous 95 caractères ascii imprimables devraient être autorisés par l’interface ( http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#cite_note-10 ) et celle-ci devrait accepter la saisie de la clé sous la forme des 64 caractères hexadécimale calculée à partir du SSID ( http://jorisvr.nl/wpapsk.html ).

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.

Bonjour,

Après avoir pris la température sur quelques bugs ici-même ou d’autres forums, je pense que c’est peine perdue, mais j’ouvre quand même un ticket pour référencer le problème. J’ai cru comprendre qu’il n’y a aucun recours pour les problèmes de ce type…

Free m’a passé en IP mutualisée sans me prévenir il y a un peu plus d’une semaine. J’utilise la Freebox en mode bridge avec un autre routeur derrière configuré en IP fixe, et je suis auto-hébergé, donc plus d’Internet et d’accès au serveur. Tout fonctionnait parfaitement depuis au moins 6 ans avec l’ancienne IP…

Après avoir compris la source du problème, dans l’urgence j’ai activé l’option IP Full-stack dans l’espace abonné, Free m’a attribué une nouvelle IP, dans le bloc 82.64.xx.xx, celle d’origine était en 88.182.xx.xx. J’ai mis à jour l’IP du routeur et mes zones DNS.
Jusque là tout fonctionne… si ce n’est que les mails sont rejetés pour motif de spam.
J’ai en effet perdu le reverse DNS, nécessaire pour avoir des chances de ne pas être rejeté pour cause de spam.

Problème: j’ai bien essayé dans l’espace abonné de supprimer l’ancien reverse DNS (qui était donc défini sur l’ancienne IP), puis de l’ajouter à nouveau pour la nouvelle adresse IP. Le changement est bien accepté, mais après plusieurs jours d’attente, le reverse DNS pointe toujours sur 82-64-xx-xx.subs.proxad.net plutôt que mon propre nom de domaine.

Je vois des problèmes similaires en #21875 et #26823 . Mais dans mon cas je suis toujours en v5 ADSL (pas de fibre ou de box avec un tas de fioritures), et le problème est survenu après un passage intempestif et mal-venu en IP mutualisée.

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.

Bonjour,

Depuis une mise à jour de la freebox crystal, mes équipements n’arrivent plus à choper une adresse ip depuis mon serveur dhcp qui est différent du réseau de la freebox.

Je reste à votre disposition pour des compléments d’informations.

Bonjour,

Depuis plusieurs semaines, il m'est impossible de télécharger / mettre à jour en ipv4 des applications Android sur le playstore officiel depuis ma connexion Free.

En cause, le routeur g-pni-mrs-2.routers.proxad.net qui boucle et n'arrive pas à joindre le serveur Google rr6.sn-4gxx-hgns.gvt1.com.

Pour illustrer, voici le résultat d'un traceroute vers rr6.sn-4gxx-hgns.gvt1.com [64.15.118.19]
[…]
8 28 ms 29 ms 29 ms g-pni-mrs-2.routers.proxad.net [212.27.40.50]
9 * * * Délai d’attente de la demande dépassé.
10 16 ms 26 ms 41 ms g-pni-mrs-2.routers.proxad.net [212.27.40.50]
11 * * 9 ms free-pni-mrs-2.routers.proxad.net [212.27.40.49]
12 28 ms 36 ms 24 ms g-pni-mrs-2.routers.proxad.net [212.27.40.50]
13 * * * Délai d’attente de la demande dépassé.
14 46 ms 49 ms 47 ms g-pni-mrs-2.routers.proxad.net [212.27.40.50]
15 15 ms * * free-pni-mrs-2.routers.proxad.net [212.27.40.49]
16 32 ms 31 ms 49 ms g-pni-mrs-2.routers.proxad.net [212.27.40.50]

Merci d'avance