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

  • Status À investiguer
  • Percent Complete
    0%
  • Task Type Anomalie
  • Category LAN
  • Assigned To
    mbizon
  • Operating System Tous
  • Severity Low
  • Priority Very Low
  • Reported Version 3.3.5
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 3
  • Private
Attached to Project: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Opened by broucaries - 07/01/2017
Last edited by rfliedel - 17/01/2017

FS#21048 - En mode bridge l'adresse fd0f:ee:b0::1 n'existe pas

Il semble que l’adresse fd0f:ee:b0::1 n’est pas up en mode bridge, ce qui ne permet pas d’acceder à la freebox tant qu’il n’y a pas de synchro.

Je peux utiliser l’adresse link local mais ca pose des problèmes pour la router

BTW quel est le MTU pour cette addresse 1500 ou 1480 ?

ip addr
...
31: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default qlen 1000

  link/ether 14:cc:20:0c:78:5e brd ff:ff:ff:ff:ff:ff
  inet6 fd0f:ee:b0::2/64 scope global 
     valid_lft forever preferred_lft forever
  inet6 fe80::16cc:20ff:fe0c:785e/64 scope link 
     valid_lft forever preferred_lft forever

...

ip route get fd0f:ee:b0::1
fd0f:ee:b0::1 from :: dev eth0 proto kernel src fd0f:ee:b0::2 metric 256 pref medium

ping6 fd0f:ee:b0::1
PING fd0f:ee:b0::1 (fd0f:ee:b0::1): 56 data bytes

— fd0f:ee:b0::1 ping statistics — 3 packets transmitted, 0 packets received, 100% packet loss

socat - tcp6-connect:[fd0f:ee:b0::1]:80
GET /
2017/01/07 16:21:46 socat[18667] E connect(5, AF=10 [fd0f:00ee:00b0:0000:0000:0000:0000:0001]:80, 28): Host is unreachable

ping6 fe80::XXX:78ff:fe1c:2b77%eth0
PING fe80::XXX:78ff:fe1c:2b77%eth0 (fe80::6aa3:78ff:fe1c:2b77%eth0): 56 data bytes
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=0 ttl=64 time=0.494 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=1 ttl=64 time=0.465 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=2 ttl=64 time=0.427 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=3 ttl=64 time=0.427 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=4 ttl=64 time=0.417 ms

socat - tcp6-connect[fe80::XXX:78ff:fe1c:2b77%eth0]:80
2017/01/07 16:24:42 socat[18794] E unknown device/address “tcp6-connect[fe80::XXXX:78ff:fe1c:2b77%eth0]”

root@OpenWrt:~# socat - tcp6-connect:[fe80::XXXX:78ff:fe1c:2b77%eth0]:80
GET /
<!DOCTYPE HTML>

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="user-scalable=no,width=640" />
    <title>Freebox OS</title>
    <link rel="stylesheet" href="resources/css/ext-theme-classic.css?v=6fc705ae37cb6900959981efd00a2c07d28b9c34">
    <link rel="stylesheet" href="resources/css/btn.css?v=f69a1aa3c216108c791625a61937dc3c640a4cdf">
    <link rel="stylesheet" href="resources/css/fbx.css?v=f06254ed6d39675d818e6f4cab9d30a675bc2d61">
    <script type="text/javascript">//<![CDATA[
        FbxConf = {};
        FbxConf.apiBaseUrl = '/api/v3/';
        FbxConf.uploadBaseUrl = '/api/v3/upload/';
        FbxConf.csrfToken = '';
        FbxConf.firmwareVersionMajor = '3';
        FbxConf.firmwareVersionMinor = '3';

        var _paq = _paq || [];
        _paq.push(["trackPageView"]);
        _paq.push(['setCustomVariable', 1, 'FromExt', '0', 'page']);

        FbxFilenames = {
          "expressInstall": "expressInstall.swf?v=1c12004633e89d6de3bbe4a190093a537bdecebe",
          "hlsplayer": "hlsplayer.swf?v=95b2f91b30e78015a68202ac95f65a9be7d0acc9",
        };

    //]]></script>
    <script src="resources/js/freeboxos.min.js?v=21599b783dddcd2de0e32449ea236c1b13e2394e"></script>
    <script src="resources/js/jquery.min.js?v=bfa700339185fcaa1b8388a62eb3285461f7dcb9"></script>
    <script src="resources/js/swfobject.min.js?v=760434d819abc468eb420ccd7df39198cbf6a638"></script>
</head>
<body>
</body>
pywy commented on 07.02.2017 15:32

Je confirme, même chose constatée de mon coté.

Du neuf depuis l'ouverture ?

Est-ce résolu ?

Des nouvelles ?

Que constatez-vous de nos jours avec Freebox OS 4.2.3 (et 4.2.4 pour Pop) ?

Bonjour,

Un an après, avec un Freebox Server Pop (v8) en mode bridge, firmware 4.3.4, le constat reste le même : l'ipv6 locale fd0f:ee:b0::1 n'est toujours pas joignable, malgré les mises à jour, ce qui est problématique, notamment pour les flux RTSP TV (Rash Player, et donc sous-titres inaccessibles sur l'interface OQEE TV) (tâche en lien, notamment : https://dev.freebox.fr/bugs/task/34909)

Pourrait-on avoir un peu de visibilité sur ce problème, car en mode routeur cette adresse est pourtant accessible…

Merci d'avance.

Des nouvelles ? Toujours le même problème

@SwHawk J'ai vu que vous faite un double nat. Pouvez vous partager la config ?

@broucaries, malheureusement, un double-NAT pour les sous-titres RTSP n'est pas facilement réalisable, et je n'ai pas le temps ni l'énergie de vérifier quels ports sont nécessaires à la visualisation des sous-titres… Je suis actuellement en bridge, et il semblerait que les sous-titres aient été rendus accessibles en mode DASH (time-shifting, start-over, et donc seul mode accessible en bridge car cette adresse locale n'existe pas… ) au moins pour quelques chaînes. C'est dommage qu'il n'y ait aucune réponse sur ce sujet malgré l'ancienneté du rapport, et le fait qu'il soit aisément reproductible… Surtout quand il touche à l'accessibilité des programmes offerts par l'abonnement…

Dans l'idée, un premier état de ce qui pourrait être fait serait de compiler l'ensemble des adresses IPv6 correspondant au streaming via Oqee, une analyse par tcpdump ou wireshark permet de déterminer quels sont les noms de domaines associés, et donc normalement une requête DNS classique permettrait de trouver les adresses IPv6 correspondantes. Une fois celà fait, l'étape délicate d'un point de vue sécurité arrive : ouvrir les connexions entrantes uniquement vers le player POP, depuis ces IPs, et ce sur n'importe quel port… Ça pose tout de même quelques problèmes de sécurité (si quelqu'un usurpe les IP des serveurs de streaming oqee, il peut donc techniquement obtenir un accès à votre player POP en profitant d'une vulnérabilité que votre firewall ne permet pas, en temps normal, de profiter), et ce n'est pas quelque chose que je souhaite risquer chez moi… Analyser le trafic avec et sans sous-titres pour déterminer les ports en question… Voir s'il n'y a pas une plage de ports dans lesquels ces échanges interviennent, et si c'est le cas restreindre les connexions depuis ces IP uniquement, et dans cette plage de ports uniquement… Autant dire que ça demande du temps, de l'investissement, et que ce n'est pas à nous de déterminer tout ceci… Au pire ces informations pourraient être mises à disposition des utilisateurs en mode bridge, lesquels se débrouillent pour adapter leur topologie réseau et leur configuration de firewall et/ou routeur pour permettre ces flux ou non. Au mieux, cette adresse est aussi mise à disposition des utilisateurs en mode bridge, afin de pallier le problème une bonne fois pour toutes…

Je suis bien conscient qu'utiliser le mode bridge demande une connaissance plus poussée des technologies, toutefois le service télévision est fourni que le bridge soit activé ou non, et donc les services afférents, notamment lorsqu'ils touchent à l'accessibilité des contenus aux personnes présentant des déficiences, devraient l'être également… Accessoirement, je possédais une freebox mini 4K avant de passer sur la POP, je suis désolé de dire que les sous-titres étaient accessibles en temps réel… Je suis bien conscient que la technologie de streaming offerte sur la mini 4K est différente de celle présentée par Oqee, mais tout de même…

@broucaries: Qu'en est-il de votre ticket ?


J'ai fait une demande il y a fort longtemps de remplacer "bridge-utils" par "iproute2":
- https://dev.freebox.fr/bugs/task/34731

Cela devrait résoudre pas mal de problèmes avec le mode Bridge.

PS : Avant j'avais aussi demandé la mise à jour de "bridge-utils", cela n'a pas été fait.
Note : ce projet n'est plus développé de nos jours d'où iproute2.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing