Utiliser son propre routeur pour la fibre optique (orange)

[Edtech]

Etant passé il y a quelques semaines à la fibre optique chez Orange (offre 200/50Mbps), j'ai tout de suite voulu me débarrasser de la LiveBox et de ses limitations.

Pour bien cerner le problème, il faut savoir que lorsque Orange (et sans doute les autres) viennent vous installer la fibre, le technicien pose un boitier dans lequel arrive directement la fibre optique. Ce boitier est relié à un convertisseur qui permet de passer de la fibre à l'Ethernet.

Il faut donc pour se passer de la fibre, soit connecter son PC directement à la sortie ethernet (mais dans ce cas vous n'aurez pas de réseau local), soit se procurer un routeur possédant une entrée EWAN, ce qui est assez rare.

Personnellement, j'ai fait l'acquisition d'un Billion Bipac 7800DXL (disponible ici) qui est un modem/routeur permettant d'utiliser en entrée, soit de l'ADSL2+, soit une clef 3G ou 4G connectée en USB, soit de l'ethernet (EWAN) à 1Gbps dans les deux sens. Faites bien attention au débit supporté en entrée par votre routeur ! Ce serait dommage de vous brider dès le départ !

Si vous cherchez sur le net, vous trouverez quasi exclusivement comment relier directement le boitier à un ordinateur et non à un routeur.

Voici comment configurer la connexion avec le 7800DXL (mais la procédure est équivalente sur les autres routeurs).

 

Ancien mode de connexion (pour les zones non-IPv6) :

Chez Orange, la connexion est toujours en PPPoE (il n'y a que chez OVH il me semble où c'est de l'IPoE si vous êtes dégroupés). Il vous faut donc fournir votre identifiant et votre mot de passe (ce n'est pas nécessaire en IPoE).

 

L'autre paramètre très important est le VLAN_ID. Il permet de différencier le type de flux qui arrive sur la port EWAN. Voici les valeurs pour Orange :

- 835 pour Internet.
- 838, 839, 840 et 841 pour la télévision.
- 851 pour la téléphonie sur IP.

 

Nouveau mode de connexion (pour les zones IPv6) :

Orange est enfin passé en IPoE. Mais au lieu de s'identifier en automatique via le protocole LLC comme OVH, c'est l'option 90 (DHCP AuthSend) qui est utilisée.

Actuellement, le Billion 7800DXL ne supporte pas cette option (le fabricant est en train de voir s'il peut rajouter cette option dans une mise à jour firmware, le sujet est ici : http://www.billion.uk.com/forum/viewtopic.php?f=18&t=8666).

Le VLAN_ID change pour ceux en IPoE. Il s'agit du 832 (et plus le 835).

 

Configuration de la TV

frederic09 a trouvé comment configurer le routeur pour avoir accès à la télévision Orange. Voici le paramétrage qui va bien :

Une fois cela fait, votre connexion devrait fonctionner.

[Killator]

Ah ! Ça c'est top comme partage !

N'empêche... Fibre > Convertisseur > Livebox... Quel gâchis ! Je comprends tout à fait la manoeuvre...

Après pour le PPPoE, tu peux pas y faire grand chose...

Sinon petites questions:

Tu as eu ces infos comment ? Le technicien qui est venu posé ta fibre va bien quand même ?
L'IPv6 marche bien ?

[Edtech]

Le technicien n'a pas pu me renseigner. Lui n'a qu'un netbook avec un Linux spécialement configuré pour activer la ligne et paramétrer la LiveBox, rien d'autre. Par contre, il a fait un boulot très soigné côté installation physique. Ça demande une bonne vue (une fibre c'est presque un cheveux !) et d'être très précis et méthodique dans son boulot.

Du coup, j'ai conservé la LiveBox 15 minutes le temps de fouiller un peu sur le net et de trouver le fameux 835. Puis j'ai mis en route mon modem/routeur et rendu le matériel à la boutique Orange du coin.

Pour l'IPv6 tu repasseras, il semblerait que ça ne soit pas disponible (le routeur ne trouve rien).

PS: La Livebox ne dispose d'aucune information sur la paramétrage de la connexion, donc inutile de chercher de ce côté là !

[Killator]

Merci pour le complément d'info

Pas d'IPv6... C'est quand même abusé... C'est trop demander de mettre en place une petite passerelle 6to4rd ?

Pour le "835", c'est pas étonnant... Un héritage de l'encapsulation des lignes ADSL dans le réseau ATM qui se faisait sur les VP/VC 8/35.

D'ailleurs si vous avez bonne mémoire, les drivers de connexion des premiers modem ADSL (genre la raie manta) "composaient" un numéro du type 8,35...

Le reste des channel est venu après avec l'arrivé des services téléphonie & TV par ADSL.

Maintenant, on s'en fout un peu car les liaisons DSLAM sont nativement fibre ou en Gigabyte Eth... (mais il doit rester pas mal d'ATM quand même chez FT)

(papy réseau vous remercie de votre attention )

[Masteromer]

Merci pour le partage !

Mais as-tu fais des mesures pour comparer l'avant/après de l'installation ?

Ca peut etre cool de voir le gain pris !

[Edtech]

C'est à dire ? Entre la Livebox et mon routeur ? J'ai fait un speedtest et les résultats sont identiques. La nouvelle Livebox fait bien son boulot. Après, je ne l'ai utilisée qu'un quart d'heure donc bon... En tout cas, l'interface est très pauvre pour des geeks comme nous, mais je pense que c'est pas trop mal conçu pour des utilisateurs classiques.

Bon, le 7800DXL est lui très, très très riche, même pour des geeks

[Masteromer]

Ouai je parlais d'un speedtest ! Ok.

DOnc ça reste utile si on souhaite faire des choses impossibles a faire avec un routeur FAI ^^

[Killator]

45MB/s en upload... Moi qui fait de l'hébergement "à domicile" depuis plusieurs années... Ca me laisse rêveur !

[Edtech]

Oui, voilà. Ou si tu choppes une connexion en 1Gbps

Ou simplement quand comme moi, tu détestes les box des FAI qui ne permettent aucun réglage un peu avancé et dans lesquelles, on sait jamais, peuvent être introduit des espions, DPI ou autres bridages !

[toTOW]

Ou si ta connu les premières box qui plantaient à la moindre sollicitation un peu violente (une mule ou torrent agressif par exemple) ... sans oublier ceux qui n'ont que faire des options à la noix comme la TV ou le téléphone ...

Par contre pour l'IPv6 chez Orange, j'espère que t'es pas pressé ... à mon avis on est pas près d'en voir.

[RaphAstronome]

D'ailleurs si vous avez bonne mémoire, les drivers de connexion des premiers modem ADSL (genre la raie manta) "composaient" un numéro du type 8,35...

Moi sur le papier pour la connexion ADSL raie manta 512 kbps j'ai :

Nous vous rappelons les numéros de téléphone à composer selon votre type d'abonnement :

Wanadoo Intégrale : 08 60 88 80 80

autre types d'accès : 08 60 00 84 84

Beaucoup de 8 mais aucun 35.

D'ailleurs je me demande à quoi ça pouvait bien servir ce numéro car en 56k c'est évidant mais pour l'ADSL ...

Sinon pour l'IPv6, j'en viens même à me demander si ils ne nous mettrait pas plutôt tous derrière un gros NAT façon téléphone plutôt qu'en IPv6.

[Edtech]

Moi je pense que de ne pas passer à l'IPv6 est un moyen de contrer une certaine concurrence. Je suis abonné à la mailing list de IPv6 (G6 asso) et il en a été question.

Certains petit FAI ont un gros problème de pénurie d'IPv4 (on pense entre autres à OVH qui a dû racheter des IPv4 russes ce qui pose parfois des problèmes aux utilisateurs). Donc pour pouvoir fournir des IPv4 à tous leurs clients, ils font de la translation IPv6 vers IPv4 et c'est la grosse galère.

L'article complet (attention, c'est complexe !) :

http://www.bortzmeyer.org/6908.html

----------------------------

Auteur(s) du RFC: Y. Lee (Comcast), R. Maglione (Telecom Italia), C. Williams (MCSR Labs), C. Jacquenet (France Telecom), M. Boucadair (France Telecom)

----------------------------


DS-Lite est une des nombreuses techniques de transition / co-existence
IPv4 / IPv6. Elle est normalisée dans le RFC 6333. Ce nouveau RFC se
penche plutôt sur des problèmes opérationnels : comment déployer
DS-Lite, quels pièges éviter, etc.

DS-Lite ("Dual-Stack Lite") est conçu pour un FAI récent, qui vient
d'arriver et n'a donc pas pu obtenir d'adresses IPv4, toutes épuisées
<http://www.bortzmeyer.org/epuisement-ipv4.html>. Ce FAI a donc dû
numéroter son réseau en IPv6, et comme ses clients ont encore de l'IPv4
à la maison, et comme ils souhaitent accéder à des machines Internet
qui sont encore uniquement en IPv4, le FAI en question va donc devoir
1) NATer les adresses de ses clients (RFC 3022) vers le monde extérieur
2) tunneler leurs paquets depuis leur réseau local IPv4 (RFC 2463)
jusqu'au CGN, en passant par le réseau purement IPv6 du FAI. C'est là
que DS-Lite intervient (RFC 6333).

Apparemment, il n'y a eu qu'un seul déploiement effectif de DS-Lite
chez un vrai FAI (le RFC ne dit pas lequel) et ce RFC 6908 est
largement tiré de cette expérience réelle. Il est donc une lecture
intéressante pour les opérateurs qui aiment le concret.

Ce RFC est en deux parties : les questions liées à l'AFTR et celles
liées au B4. Vous ne savez pas ce qu'est un AFTR ou un B4 ? Vous n'avez
pas envie de lire le RFC 6333 qui explique cela ? Alors, en deux mots,
l'AFTR ("Address Family Transition Router") est le gros routeur NAT (le
CGN) situé entre le FAI et l'Internet. Et le B4 ("Basic Bridging
Broadband element") est chez le client, typiquement dans sa box et
représente le point d'entrée du tunnel, du « lien virtuel » ("soft
wire"). Prononcez les sigles à voix haute : le B4 est avant le tunnel
("before") et l'AFTR après ("after").

Donc, bien qu'il soit « après », notre RFC commence par l'AFTR (section
2). D'abord, comme DS-Lite utilise un tunnel, il va y avoir des
problèmes dus à la MTU inférieure. Le RFC recommande donc d'essayer de
faire un lien entre le B4 et l'AFTR ayant une MTU d'au moins 1540
octets pour que, après avoir retiré les 40 octets de l'encapsulation
dans le tunnel, on ait les 1500 octets d'Ethernet. Si ce n'est pas
possible, alors le B4 et l'AFTR vont devoir gérer la fragmentation.
Comme le réassemblage des paquets est une opération coûteuse en
ressources (il faut garder les fragments en mémoire tant que tout n'est
pas arrivé), la tâche va être particulièrement lourde pour l'AFTR (des
milliers de tunnels peuvent se terminer sur un seul AFTR). Il faut les
dimensionner largement ! (C'est un problème général des CGN.)

Ensuite, il faut penser à la journalisation. Le principe de DS-Lite est
que tous les clients du FAI partageront la poignée d'adresses IPv4
publiques que NATeront les AFTR. Si un client fait quelque chose de mal
(par exemple accéder à un site Web qui déplait au gouvernement), il
faut pouvoir l'identifier. Un observateur situé à l'extérieur a vu une
adresses IPv4 du FAI et des milliers de clients pouvaient être
derrière. L'AFTR doit donc noter au moins l'adresse IPv6 du B4 (elle
est spécifique à chaque client) et le port source utilisé après le NAT
(en espérant que l'observateur extérieur ne notera pas que l'adresse
IPv4 source mais aussi le port, cf. RFC 6302).

Les adresses IP partagées sont une plaie du NAT, ce n'est pas nouveau
(RFC 6269). Par exemple, si une adresse IPv4 est mise sur une liste
noire suite à son comportement
<http://lci.tf1.fr/high-tech/2007-07/polemique-quand-wikipedia-punit-sci
ences-4890331.html>, ce seront des centaines ou des milliers de B4 qui
seront privés de connectivité IPv4. Si le destinataire ne tient pas
compte du RFC 6302 et bloque sur la seule base de l'adresse IPv4, le
support téléphonique du FAI qui a déployé DS-Lite va exploser. (Un
travail est en cours à l'IETF pour aider à l'identification de
l'utilisateur derrière un CGN. Mais il n'est pas terminé et, de toute
façon ne sera pas forcément déployé. L'obstination de tant d'acteurs à
rester en IPv4 va se payer cher.)

Un problème analogue se posera si le FAI veut faire de la comptabilité
des octets échangés, et s'il ne met pas cette fonction dans le CPE. Le
tunnel et le NAT rendront cette analyse plus compliquée (section 2.6).
À noter que le RFC 6519 normalise des extensions à Radius pour les
problèmes particuliers de DS-Lite.

Mais tout ceci n'est rien par rapport aux problèmes de fiabilité que
posent les AFTR. L'Internet normal est très robuste car les équipements
intermédiaires (les routeurs) n'ont pas d'état : s'ils redémarrent,
rien n'est perdu. S'ils s'arrêtent de fonctionner, on en utilise
d'autres. Le NAT met fin à tout cela : le routeur NAT a un état en
mémoire, la table des correspondances {adresse interne, adresse
externe} et, s'il redémarre, tout est fichu. C'est bien pire pour un
CGN : s'il redémarre, ce sont des centaines ou des milliers
d'utilisateurs qui perdent leurs connexions en cours. La fiabilité des
AFTR est donc cruciale (cf. annexe A.3 du RFC 6333). Notre RFC propose
que des AFTR de remplacement soient installés pour être prêts à prendre
le relais. Ils peuvent fonctionner en « remplacement à chaud » ("Hot
Standby"), se synchronisant en permanence avec l'AFTR primaire, prêts à
le remplacer « sans couture » puisqu'ils ont le même état, ou bien en
« remplacement à froid » ("Cold Standby"), sans synchronisation. Dans
ce second cas, l'AFTR de secours fait qu'un AFTR en panne est vite
remplacé, mais il n'y a pas de miracle : les clients doivent
recommencer toutes leurs sessions. Vue la complexité qu'il y a à mettre
en œuvre correctement la synchronisation des états, notre RFC
recommande le remplacement à froid, et tant pis si c'est moins agréable
pour les utilisateurs.

Et les performances ? Combien faut-il d'AFTR pour servir les
utilisateurs ? La section 2.8 discute de ce point et du meilleur
placement de ces équipements.

Comme avec tout CGN, DS-Lite, en centralisant les adresses IPv4, limite
les possibilités de géo-localisation. Le B4 (donc la maison de
l'utilisateur) et l'AFTR peuvent parfaitement être dans des villes
différentes (RFC 6269, section 7). Les applications ne devraient donc
pas se fier à la géo-localisation mais demander à l'utilisateur où il
se trouve, par exemple avec le protocole HELD du RFC 5985 ou en suivant
l'architecture du RFC 6280. Le RFC conseille, curieusement, de mettre
les AFTR le plus près possible des utilisateurs, pour limiter ce
problème (alors que les AFTR ont besoin d'une connectivité IPv4, et que
le réseau du FAI ne la fournit pas forcément, sinon il n'aurait pas
besoin de DS-Lite).

Autre problème douloureux avec les CGN (dont DS-Lite), les connexions
entrantes. Contrairement au NAT traditionnel, celui fait par la "box" à
la maison, plus question de configurer sa "box" via une interface Web
pour rediriger certains ports. Et plus moyen de se servir d'UPnP. Les
éventuelles redirections doivent être sur l'AFTR, un engin largement
partagé. Donc, pas question de demander une redirection du port 80...

Pour « programmer » l'AFTR, lui demander d'ouvrir certains ports en
entrée, notre RFC recommande d'installer un serveur PCP ("Port Control
Protocol") sur les AFTR. Il n'est pas évident que cela soit une
solution satisfaisante. D'une part, il existe encore très peu de
clients PCP (par rapport aux clients UPnP). D'autre part, l'AFTR étant
partagé entre plusieurs clients ne se connaissant pas, rien ne dit que
la coexistence se passera bien et que les opérateurs accepteront
d'ouvrir PCP à leurs clients.

Voilà, c'étaient les points essentiels pour les AFTR, lisez la section
2 du RFC si vous voulez la liste complète. Et les B4 ? Ils font l'objet
de la section 3. D'abord, le problème du DNS. Le B4 est censé
s'annoncer comme résolveur DNS et relayer les requêtes DNS au dessus
d'IPv6 vers l'extérieur. Ce faisant, il est important qu'il suive les
recommendations pour les relais DNS du RFC 5625 (en pratique, la grande
majorité des "boxes" et des petits routeurs bas de gamme violent
affreusement ces recommendations). C'est notamment nécessaire si on
veut que DNSSEC fonctionne.

Si un client sur un réseau local IPv4 fait des requêtes DNS en IPv4
vers une adresse qui n'est pas celle du B4, ces requêtes seront
tunnelisées et NATées comme n'importe quel trafic IPv4. Compte-tenu du
fait que, du point de vue du NAT, chaque requête DNS est une session à
elle seule, l'augmentation de la charge sur les AFTR sera sensible. Ce
n'est donc pas conseillé.

Le B4 étant le début du réseau de l'opérateur, et beaucoup de choses
dépendant de sa configuration et de son bon fonctionnement, il est
important que l'opérateur puisse y accéder à distance, et au dessus
d'IPv6, pas au dessus du lien virtuel (qui a davantage de chances
d'avoir des problèmes).

À propos d'administration et de supervision du réseau, il est important
que les AFTR répondent aux paquets utilisés pour ping et traceroute,
afin que le B4 puisse tester que la connectivité IPv4 au dessus du
tunnel marche bien. Des adresses IPv4 spéciales ont été réservées pour
cela (rappelez-vous que, si vous déployez DS-Lite, c'est que vous
n'avez pas assez d'adresses IPv4 publiques), 192.0.0.0/29. Les AFTR
sont censés tous répondre aux paquets envoyés à 192.0.0.2.

_______________________________________________
G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr)
Liste IPv6tech IPv6tech@g6.asso.fr
Info : http://mail.g6.asso.fr/mailman/listinfo/ipv6tech

[seboss666]

45Mbmps d'upload :bave:

Sinon le CGN c'est l'horreur, ça rend le réseau complètement asymétrique (dans le cul pour ceux qui auto-hébergent). On devient de simples consommateurs, c'est le mal absolu. Belgacom a commencé à déployer ça de manière un peu silencieuse à ses clients, ça gueule pas mal.

Sinon je sais plus où j'ai lu ça (wikipedia peut-être), mais ipv6 chez Orange pas prévu avant 2014. Suis bien content d'être chez Free moi (mais mon routeur supporte pas :( )

[RaphAstronome]

Très intéressant.

Dommage que j'avais pas cela à la FAC avec le prof de réseau qui défendait ce genre de système et qui soutenait q'IPv6 ne servait à rien.

Mais les personnes qu'il faudrait convaincre c'est surtout les politiques car avec le manque d'IPs il y a un gros risque d'abus de position dominante mais ça c'est pas gagné.

[Etre_Libre]

Content de voir qu'avec Orange c'est possible de se brancher directement à l'ONT (convertisseur fibre vers ethernet) car avec SFR fibre j'avais testé et ça ne marchait que quelques heures, ensuite ça coupait si je ne laissais pas la Neufbox (apparemment une protection, m'a-t-on dit).

Suite à ça, avec Orange fibre je n'avais même pas essayé.

Reste à voir dans la durée si Orange autorise bien cela et si ça tient, enfin tant mieux

[treflemard]

Moi je pense que de ne pas passer à l'IPv6 est un moyen de contrer une certaine concurrence. Je suis abonné à la mailing list de IPv6 (G6 asso) et il en a été question.

Certains petit FAI ont un gros problème de pénurie d'IPv4 (on pense entre autres à OVH qui a dû racheter des IPv4 russes ce qui pose parfois des problèmes aux utilisateurs). Donc pour pouvoir fournir des IPv4 à tous leurs clients, ils font de la translation IPv6 vers IPv4 et c'est la grosse galère.

Salut,

je ne suis pas pour autant persuadé qu'activer l'ipv 6 chez orange permette de libérer des ipv4 puisque quelque soit le FAI, quand on a l'ipv6 activée, on garde notre ipv4. d'un autre côté, j'ai activé l'ipv 6 depuis plusieurs mois et force est de constater que beaucoup de sites ne sont pas encore compatible IPV6. ( ipv 6 pas activée côté hébergement ou ipv6 pas "gérée" par les CMS utilisés qui stockent des ips en base de données). Et je pense que la route est encore longue avant que ne serait-ce que 50 % du web ne soit compatible IPV6. La migration prendra du temps de toute façon tant que l'ipv6 n'est pas activée par défaut ou mise en avant sur les box et côté hébergeur.

Pour OVH, ils n'ont pas tant que çà de clients autour de 30 à 35k je l'ai lu récemment . Je pense qu'ils ont assez d'ipv4 pour tout le monde. ( Attention, OVH communique sur le nombres de paires et pas de ligne. - 1 ligne SDSL peut utiliser 4 paires ). Je pense que c'est plutôt ovh côté hébergement qui est "short" en ip. Ils construisent beaucoup de Dcs, je ne sais pas si ils sont arrivés à acheter suffisamment d'ip. Ce sont pas plutôt les FAI asiatiques qui sont méga short ??

OVH a aussi récupérer des ips 5.x.y.z pour les hébergements qui posent un soucis avec le logiciel hamachi ...

Pour orange, il me semblait avoir entendu que l'ipv6 serait testé à partir de ce printemps. ( après, que veut dire tester ... bonne question).

[Etre_Libre]

J'ai honte :

mars 2011

mai 2013

Tu sais, chez moi je suis en ADSL, la fibre je ne l'ai testé que chez d'autres gens / structures Modifié le 6 mai 2013 par Etre_Libre

[Carpe_Diem]

Mais bon, ça colle avec les 28 MB/s et 1 MB/s promis sur le site.

On verra en Fibre, l'agrume devant arriver... mais quand, ça, on n'en parlera pas ! lol

Correction : 28 Mb et 1 Mb.

Modifié le 1 juin 2013 par Carpe_Diem

[Edtech]

Juste pour information, jusqu'à ce jour (ça fait un mois maintenant donc), aucun problème de connexion. La ligne tient très bien.

De légers ralentissements sur Youtube le soir (boouh, c'était nickel chez OVH) mais comme je ne suis pas un gros consommateur, pas bien gênant.

Sur les torrents, j'ai du mal à dépasser les 7Mio/s en entrant (et je suis à fond en sortant, dans les 5.5Mio/s environ) mais ça vient sans doute des pairs qui débitent pas assez. Sur Steam, ça passe à 25Mio/s, du coup, je ne stocke plus de jeux chez moi

[Azax]

J'avoue que je ne savais pas que cela existait (se brancher direct à la fibre).

Dans mon cas pour le moment ça ne m'est pas utile mais je garde ce mode de fonctionnement sous le coude, Merci bien !

Juste pour infos sinon, tu dis que le 7800DXL ne supporte pas l'ipv6 (ou qu'il ne trouve rien cf ton post plus haut). Pourtant sur ce lien http://www.billion.uk.com/product/wireless/7800dxl.htm

Il précise bien "IPv6 support".

Sinon je n'ai pas trouvé ou l'acheter :/ Pour avoir une idée du prix !

EDIT: ah je viens de le trouver au alentour de £116.66 et j'ai vu pour ton autre post comme quoi tu n'a pas réussis à faire fonctionner l'ipv6 sur ton W8.

Modifié le 30 mai 2013 par Azax

[Edtech]

En fait, le routeur est full IPv6 et le gère très très bien.

Avant, j'avais la génération précédente de ce routeur et je n'ai jamais réussi à faire fonctionner l'IPv6 chez OVH. Mais le routeur n'était pas en cause car en mode bridge, ça ne fonctionnait pas non plus.

OVH avait commencer à investiguer (j'avais mis une machine sous Linux à disposition derrière le routeur en bridge) mais comme je suis passé à Orange, ils n'ont pas eu le temps de trouver le problème. Mais le routeur obtenait bien son IPv6, le LAN gérait bien la plage, les PC avaient leur adresse. Mais les DNS chiaient côté LAN et le net était inaccessible.

Orange ne propose tout simplement pas l'IPv6 pour le moment. Dès que ça sera le cas, mon routeur devrait automatiquement la prendre en compte.

Sinon, pour l'acheter, il y a un lien dans mon premier post.

PS: J'ai vendu mon ancien routeur à un admin du forum, il pourra vous dire ce qu'il en pense !

https://forum.nextinpact.com/topic/166024-vendu-modemrouteur-adsl2-bipac-7800n/?hl=bipac

[RaphAstronome]

Le routeur que m'a vendu Edtech marche bien mais par contre étant chez Orange je n'ai pas le moyen de tester ce fameux "IPv6" .

[CaseyN]

Mais bon, ça colle avec les 28Mo MB/s et 1 MB/s promis sur le site.

On verra en Fibre, l'agrume devant arriver... mais quand, ça, on n'en parlera pas ! lol

Attention, le 28 Mega de Free en ADSL sont Mbps (megabits par seconde) et non MBps (megaByte - MegaOctet en français - par seconde). Y'a un rapport de 8 hein ! 1MBps = 1Mo/s = 8 Mbps.

[Carpe_Diem]

Merci du rappel, j'avais pas fais gaffe.

Avec 22Mb et 0.99Mb, c'est quasi conforme à l'offre alors (atténuation 16db)

La fibre a été montée par l'agrume cette semaine, voir la suite maintenant.

[seboss666]

Y'a plus qu'à attendre 4 ans qu'ils raccordent ton logement maintenant