Nous allons tâcher d'apporter des éléments de réponses à cette question, au regard des éléments qu'on peut mettre en évidence avec nos téléphones, ordinateurs (en partage de connexion), et des outils réseaux standards fournis avec n'importe quel UNIX.
Evidement, le but de ce billet n'est aucunement d'apporter une réponse ferme et définitive, seulement des hypothèses de réponses les plus probables.
Quelques rappels de faits vérifiables:
Fonctionnement de l'itinérance Orange:
Lorsqu'on est connecté via l'itinérance Orange, nous passons par une antenne Orange mais aussi un lien d'interconnexion entre le réseau de Free et celui d'Orange.
Abonné Free Mobile <---> Antenne Orange <---> Interconnexion Free / Orange <---> Coeur de réseau Free.
De ce fait, il y a déjà au moins une limitation liée à la capacité (bande passante) du lien d'interconnexion entre Free et Orange.
Les bridages constatés:
- Tout d'abord, on constate que seuls certains services sont bridés. En l'occurrence, le web (et encore pas tous les sites, google.com et mobile.free.fr version mobile ne le sont pas par exemple), YouTube, les services de streaming...etc. Exemple bien connu de service non bridé sur l'itinérance, les Speedtests (tests de débits).
- De plus lorsqu'on télécharge des fichiers, on remarque que tous les types de fichiers ne sont pas bridés (un fichier multimédia le sera, un fichier texte, même de plusieurs centaines de Mo, le sera pas. On peut d'ailleurs berner le système dans ce dernier cas en changeant l'extension (si évidement le fichier est sur un serveur personnel)).
Exemple de filtrage sur l'extension, via http://test-debit.free.fr/
Fichier en .rnd (extension non reconnue, donc non filtrée):
Fichier en .iso (extension reconnue et filtrée):
Comme on peut le voir, la différence est flagrante. Le fichier en .iso ne dépasse pas quelques Ko/sec, alors que celui en .rnd, non filtré, atteint de très bons débits (plus de 500Ko/sec)
- Au niveau des couches TCP (couche transport - couche 4) et IP (couche réseau - couche 3), et supérieures, on ne passe jamais par un routeur Orange, on est directement connecté sur le coeur de réseau IP de Free.
Petit rappel du modèle OSI
Il faut rappeler que les informations relatives au port réseau sont au niveau de la couche transport (couche 3), et les informations relatives aux protocoles (et aux données qu'ils encapsulent) tel que HTTP, FTP, ...etc, sont au niveau de la couche 7. De ce fait, en dessous de ces couches, les filtrages possibles sont beaucoup moins précis (sauf bricolages).
Or lorsqu'on est connecté via l'itinérance Orange, on dispose d'une IP Free Mobile directement (et non Orange) (ex dans mon cas en itinérance: 37.160.212.70 (cf http://whois.urih.com/record/37.160.212.70/)
inetnum 37.160.0.0 - 37.163.255.255
Et un comparatif entre un traceroute via le réseau propre de Free et un traceroute via l'itinérance Orange, ne montre pas de passage par des routeurs d'Orange dans le cas de l'itinérance. Ils sont très similaires:
netname MOBILE-USERS-BLOCK
country FR
admin-c APfF1-RIPE
tech-c TPfF1-RIPE
status ASSIGNED PA
mnt-by FREEM-MNT
source RIPE # Filtered
person Administrative Person for Free Mobile
address 8 rue de la ville l'eveque
address 75008 PARIS
phone +33 1 73 50 20 00
nic-hdl APfF1-RIPE
mnt-by FREEM-MNT
source RIPE # Filtered
person Technical Person for Free Mobile
address 8 rue de la ville l'eveque
address 75008 PARIS
phone +33 1 73 50 20 00
nic-hdl TPfF1-RIPE
mnt-by FREEM-MNT
source RIPE # Filtered
route 37.160.0.0/12
origin AS51207
mnt-by FREEM-MNT
Réseau propre:
$ traceroute www.yahoo.com
Itinérance Orange:
traceroute: Warning: www.yahoo.com has multiple addresses; using 46.228.47.114
traceroute to ds-eu-fp3.wa1.b.yahoo.com (46.228.47.114), 64 hops max, 52 byte packets
1 192.168.43.1 (192.168.43.1) 3.843 ms 2.544 ms 2.525 ms
2 10.255.255.5 (10.255.255.5) 59.337 ms 105.265 ms 55.941 ms
3 10.255.255.121 (10.255.255.121) 79.263 ms 69.433 ms 109.217 ms
4 10.255.255.117 (10.255.255.117) 127.563 ms 243.704 ms 73.813 ms
5 10.255.255.114 (10.255.255.114) 160.518 ms 64.230 ms 132.078 ms
6 cbv-mx9-1-tci2.intf.routers.proxad.net (194.149.161.134) 99.403 ms 191.127 ms 394.480 ms
7 78.254.250.169 (78.254.250.169) 432.949 ms 232.300 ms 292.984 ms
8 bzn-crs16-2-be1009.intf.routers.proxad.net (194.149.161.9) 164.784 ms 148.527 ms 289.920 ms
9 bzn-crs16-1-be1106.intf.routers.proxad.net (212.27.59.101) 331.177 ms 153.925 ms 288.909 ms
10 londres-6k-1-po101.intf.routers.proxad.net (212.27.51.186) 275.255 ms 87.623 ms 85.754 ms
11 ge-1-1-0.pat1.the.yahoo.com (195.66.224.129) 99.509 ms 69.767 ms 81.334 ms
12 ae-4-pat2.iry.yahoo.com (216.115.104.72) 88.072 ms
ae-4.pat1.iry.yahoo.com (66.196.65.152) 72.689 ms 88.274 ms
13 ae-2.msr1.ir2.yahoo.com (66.196.65.157) 125.883 ms
ae-3.msr2.ir2.yahoo.com (66.196.67.253) 125.865 ms
ae-3.msr1.ir2.yahoo.com (66.196.67.243) 73.766 ms
14 et-17-9.bas2-2-prd.ir2.yahoo.com (217.146.185.166) 108.981 ms
et-17-18.bas2-2-prd.ir2.yahoo.com (77.238.186.49) 109.252 ms
et-18-17.bas2-2-prd.ir2.yahoo.com (217.146.185.168) 108.802 ms
$ traceroute http://www.yahoo.com
traceroute: Warning: http://www.yahoo.com has multiple addresses; using 46.228.47.115
traceroute to ds-eu-fp3.wa1.b.yahoo.com (46.228.47.115), 64 hops max, 52 byte packets
1 192.168.43.1 (192.168.43.1) 5.179 ms 1.944 ms 1.977 ms
2 10.255.255.9 (10.255.255.9) 107.004 ms 77.698 ms 75.541 ms
3 10.255.255.121 (10.255.255.121) 83.088 ms 90.405 ms 74.234 ms
4 10.255.255.117 (10.255.255.117) 72.881 ms 70.487 ms 69.870 ms
5 10.255.255.114 (10.255.255.114) 69.966 ms 70.421 ms 69.896 ms
6 cbv-mx9-1-tci2.intf.routers.proxad.net (194.149.161.134) 70.118 ms 69.113 ms *
7 78.254.250.169 (78.254.250.169) 85.358 ms 67.128 ms 83.947 ms
8 bzn-crs16-2-be1009.intf.routers.proxad.net (194.149.161.9) 74.020 ms 70.713 ms 77.908 ms
9 bzn-crs16-1-be1106.intf.routers.proxad.net (212.27.59.101) 72.066 ms 78.940 ms 70.940 ms
10 londres-6k-1-po101.intf.routers.proxad.net (212.27.51.186) 79.510 ms 79.923 ms 80.124 ms
11 ge-1-1-0.pat1.the.yahoo.com (195.66.224.129) 76.239 ms 78.659 ms 99.335 ms
12 ae-4.pat1.iry.yahoo.com (66.196.65.152) 90.607 ms
ae-4-pat2.iry.yahoo.com (216.115.104.72) 89.480 ms
ae-4.pat1.iry.yahoo.com (66.196.65.152) 107.801 ms
13 ae-3.msr1.ir2.yahoo.com (66.196.67.243) 87.255 ms
ae-3.msr2.ir2.yahoo.com (66.196.67.253) 108.996 ms
ae-2.msr2.ir2.yahoo.com (66.196.65.159) 90.101 ms
14 et-17-10.bas1-2-prd.ir2.yahoo.com (77.238.186.37) 98.877 ms
et-18-18.bas1-2-prd.ir2.yahoo.com (77.238.186.43) 96.366 ms
et-17-10.bas1-2-prd.ir2.yahoo.com (77.238.186.37) 89.092 ms - L'usage d'un VPN permet de débrider la connexion.
Un VPN permet de masquer un certain nombre d'informations via une connexion unique crypté, tel que les protocoles utilisés, les ports réseaux, le contenus des données échangées (types de fichiers, données en elles même).
Que permettent de dire ces éléments:
- En plus de la capacité de l'interconnexion Free/Orange elle même, on constate la présence de bridages sélectifs en fonction du service, type de fichier...etc.
Cela démontre que ce n'est pas seulement un problème de saturation de l'interconnexion, car sinon tous les services seraient touchés unilatéralement, y compris les Speedtests par exemple. Ce n'est pas le cas (on a vu que télécharger un fichier avec une extension exotique (.rnd dans le cas présent) n'était pas bridé, alors que le téléchargement d'un fichier .iso l'était. De même les Speedtests ne sont pas bridés par exemple). - Le fait que les critères de bridages soient très précis (type de fichier, protocoles...) semble indiquer que le bridage est fait à des niveaux élevés (couche 3, 4 ou supérieures).
Car même s'il existe des outils comme ebtables et/ou tc (sous Linux par exemple) pour filtrer à partir de couches plus basses (couches 1 et 2 (physique et liaison de données)), cela relève du bricolage et serait franchement une solution tirée par les cheveux de notre point de vue et présente peu d'intérêt pour Orange (qui peut simplement limiter la bande passante en fonction du prix payé par Free et donc facturer davantage Free s'il demande plus de bande passante). - Le fait qu'un VPN permette de débrider pleinement la connexion, quelque soit le service interrogé derrière, démontre également que le bridage n'est pas global mais bien spécifique (sinon là encore le VPN serait bridé)
- Enfin dernier élément, et petit rappel historique, ce n'est pas la première fois que Free met en place de la QoS sur son réseau pour limiter la facture payée à un prestataire (qui était aussi France Telecom / Orange dans ce cas historique), ils l'ont déjà fait sur l'IP/ADSL (ADSL non dégroupé) et ont été condamnés par la justice à 100 000 euros d'amendes à cause de cela (source: http://www.freenews.fr/spip.php?article11889).
Mais visiblement cela ne les a pas refroidi pour faire de même sur l'itinérance Orange sur le mobile, et on peut le comprendre, de même que sur le fixe cela leur a certainement permis d'alléger les factures de France Telecom / Orange de bien plus de 100 000 Euros (et donc l'amende à laquelle ils ont été condamnée est certainement une brindille par rapport à ce qu'ils ont gagné), le risque financier est faible également sur le mobiles.
Qui d'Orange ou Free a le plus intérêt à limiter le trafic?
Enfin, on peut se demander qui d'Orange ou de Free a le plus intérêt à limiter le trafic de façon sélective?
Quelques éléments de réponse:
- Orange facture à Free, à la fois un montant fixe, notamment relatif à la capacité d'interconnexion demandée mais aussi un montant variable
- La partie variable facturée à Free Mobile, dépend directement du trafic que ce dernier consomme, que cela soit en voix, en SMS, en MMS ou en data 3G.
De ce fait, plus les abonnés de Free Mobile consomment sur l'itinérance Orange, plus Orange facture cher à Free.
Inversement, moins Free Mobile consomme de trafic, moins la facture est lourde pour celui-ci.
Cependant, on peut aussi se demander si Orange n'a pas intérêt à limiter l'itinérance afin de ne pas pénaliser ses propres clients.
Cela étant dit, avec ses plus de 18000 sites 3G actif, et son large patrimoine de bande de fréquences disponible en 3G (20MHz duplex en 2100Mhz + 5MHz duplex en 900MHz), à mon avis le réseau d'Orange a largement les capacités de tenir le coup sans avoir recours à des limitations supplémentaires.
Mais considérons tout de même cette hypothèse comme plausible.
Il apparait donc que d'Orange ou de Free, celui qui a le plus intérêt à limiter le trafic est Free.
Mais considérons tout de même cette hypothèse comme plausible.
Il apparait donc que d'Orange ou de Free, celui qui a le plus intérêt à limiter le trafic est Free.
Bref, s'il est probable que l'interconnexion entre Free et Orange soit sous-dimensionnée (et l'épisode de mars 2012 (où là tout était saturé, y compris la voix et les SMS), montre que cela a été le cas au moins une fois de façon très visible), et qu'Orange applique peut être des restrictions pour préserver la qualité de service de ses propres client, il est probablement que Free lui aussi applique une QoS.
Rappelons également qu'à plusieurs reprises l'ARCEP (notamment suite à l'étude sur la qualité de service publiée en juin 2014), Orange ou Free ont la possibilité de saisir l'ARCEP s'ils jugeaient que l'un ou l'autre ne jouait pas correctement son rôle dans le cadre de l'itinérance.
Cependant, bien que les bridages existent depuis le printemps 2012, le président de l'ARCEP a déclaré qu'à ce jour ni Free, ni Orange n'a saisi l'ARCEP concernant l'itinérance.
Or il est évident que si Orange bridait de lui même l'itinérance sans l'accord de Free, ce dernier n'aurait pas hésité à saisir l'ARCEP (ils ont démontré par le passé qu'ils n'hésitaient pas à saisir les instances compétentes).
Xavier Niel avait répondu à un abonné par e-mail (révélé dans l'émission Envoyée Spéciale du 10 janvier 2013 - http://www.dailymotion.com/video/xwnluc_free-mobile-dans-envoye-special_tech#from=embediframe (à 23:44)), qu'Orange limitait la bande passante sur certaines antennes, cependant cela est une explication clairement insuffisante étant donné les bridages constatés, qui sont bien plus précis qu'une simple limitation de bande passante.
De ce fait, même si l'on peut considérer l'hypothèse qu'Orange limite la bande passante sur certaines antennes comme admissible, elle est insuffisante pour expliquer l'entièreté des bridages constatés qui ne se limitent pas à la bande passante.
Il semble donc très probable que ces bridages spécifiques soient au minimum mis en place soit d'un commun accord entre Orange et Free, soit par Free directement.
En effet, les éléments relevés (filtrages très précis, pas de routeurs Orange (à priori), ...etc), tend à indiquer qu'il est peu probable que le filtrage soit fait par Orange (qui devrait pour ce faire bricoler puisqu'il semble n'intervenir que dans les couches basses du modèle OSI), mais plutôt par Free qui peut non seulement le faire plus facilement, plus proprement et plus précisément, mais aussi a plus d'intérêts à le faire.
De plus, les bridages ont commencés peu après l'épisode de saturation de mars 2012. Il ne serait de ce fait pas étonnant que Free ait décidé de mettre en place ces mesures de QoS suite à cet épisode, afin de s'assurer qu'au moins la voix et les SMS fonctionnent correctement, quitte à dégrader la data en contre partie.
Ce ne serait d'ailleurs pas la première fois que Free utilise ce type d'outil. En effet (et pour des raisons tout à fait comparable d'ailleurs), Free a déjà, dans le cas de l'IP/ADSL (ADSL non dégroupé), appliqué de la QoS pour réduire la facture de la prestation non dégroupée d'Orange.
La problématique dans le cadre de l'itinérance Orange est similaire, puisqu'il s'agit également pour Free de trouver un juste milieu entre les frais engagés dans cette prestation d'itinérance Orange et la qualité de service.
Nous pensons donc que suite à l'épisode de saturation de l'interconnexion Orange/Free de mars 2012, il ne serait pas étonnant que Free ait choisit de privilégier les services voix et SMS/MMS, et ait donc mis en place une politique de QoS sur la data en itinérance Orange pour éviter que ce type d'épisode se reproduise, tout en limitant la facture payée à Orange.
Le cas de l'IP/ADSL démontre qu'ils ont déjà appliqué ce type de stratégie par le passé et donc qu'ils sont parfaitement capable de prendre ce genre de décision et de le mettre en place.
Peut on vraiment reprocher à Free de faire de la QoS?
Peut on vraiment leur reprocher de faire ce genre de choix? Pas forcément, car il y avait évidement un choix à faire suite à l'épisode de saturation de mars 2012 (qui lui touchait la totalité des services, que cela soit la voix, les SMS/MMS ou la data, en itinérance).
Est ce un bon choix? Tant qu'ils recrutent de façon importante et que cela n'écorche pas trop l'image de Free, cela est un bon choix stratégique à priori. Et pour l'instant cela semble rester le cas.
Evidement, si un nombre significatif d'abonnés venaient à quitter Free Mobile à cause de cela, là Free songera très certainement à revoir sa stratégie.
Donc tout comme dans le cas de l'IP/ADSL, il est dans l'intérêt de Free Mobile de limiter la facture de l'itinérance, et bien que cela reste qu'une hypothèse, nous considérons fort probable que les limitations mis en place sur l'itinérance Orange montrées ici, soient en grande partie imputables à Free Mobile.
Et franchement, tant que le bilan des recrutements est positifs, pourquoi s'en priveraient ils? D'autant plus qu'ils développent en parallèle leur réseau propre et donc au fur et à mesure du développement de ce dernier les limitations mises en place sur l'itinérance Orange seront de moins en moins visibles et pénalisantes pour l'utilisateur.
On voit d'ailleurs un certain nombre d'abonnés Free Mobile très satisfaits de leur abonnement car leurs lieux de vie sont plutôt bien couverts par le réseau propre. Et cela sera de plus en plus vrai au fur et à mesure du déploiement de ce réseau, qui s'est d'ailleurs accéléré ces derniers mois selon nos constations (on est maintenant dans une moyenne de 100 à 150 sites déclarés par mois alors que celle-ci était plutôt 50 à 70 sites par mois en 2012/2013).
Bref, nous pensons que Free applique au mobile la même stratégie qu'ils ont appliqué sur le fixe vis à vis de l'IP/ADSL (non dégroupé) qui leur a plutôt bien réussie (en dehors de cette amende qui est à mon avis quasiment indolore pour Free). Evidement, il y a toujours des dommages collatéraux à ces choix stratégiques, sur le fixe c'était les abonnés non dégroupés qui étaient pénalisés, sur le mobile ce sont ceux qui sont majoritairement sous itinérance Orange.
Rappelons d'ailleurs que les offres de Free Mobile sont sans engagement, et donc que les personnes non satisfaites peuvent sans soucis aller chez la concurrence qui s'est d'ailleurs globalement aligné sur les tarifs et offres de Free Mobile (à quelques détails près (tel que le fair use notamment)).
A chacun de peser le pour et le contre des différentes offres du marché, tant du point de vue tarifaire, services et qualité de services, et de faire son choix en fonction, surtout que le marché ne manque pas d'offres sans engagement que l'on peut résilier du jour au lendemain, d'autant plus que la portabilité du numéro est très simple et pratique sur le marché du mobile.
Quelques petites astuces pour vivre avec l'itinérance Orange
Vous êtes chez Free Mobile et souhaitez y rester? Il y a des solutions relativement simples pour palier aux défauts de l'itinérance Orange.
Utiliser l'option "Réduire la consommation" de Google Chrome
L'application Google Chrome pour iOS et Android, dispose d'une option permettant de compresser à la volée les données.
Cette option à pour effet de faire passer tout le trafic Web sur un proxy utilisant le protocole SPDY de Google. Ce proxy n'est pas bridée sur l'itinérance Orange, et de ce fait on contourne les bridages.
Pour activer cette option, il suffit d'ouvrir Google Chrome, d'aller dans "Paramètres" (via le menu principal), puis "Gestion de la bande passante" et enfin "Réduire la consommation des données" et activer cette option.
Utiliser un VPN
Comme indiqué plus haut dans ce billet, un VPN (Virtual Private Network) permet de crypter les données qui transitent sur le réseau, rendant inopérantes les mesures de filtrages.
Il existe tout aussi bien des offres payantes (en général 5€/mois) que gratuites de VPN. Actuellement par exemple le service No Limit VPN propose des accès gratuits qui sont tout à fait satisfaisant pour le cas présent.
11 commentaires:
"Donc Orange n'a pas connaissance de ces détails, et ne peut donc pas
effectuer de filtrage sur ces points, car pour cela il aurait fallut
qu'on passe par des équipements Orange au niveau TCP/IP ou supérieur, et
donc le voir sur les traceroutes. Seul Free peut le faire."
c'est faux, les donnés circulent en clair par leur équipments et pas besoin d'être routeur pour faire de la QoS sur critères layer3/4/7. Un simple bridge avec brtables et tc suffit à l'implémenter sous linux.
idem
Merci pour cette initiative, mais l'étude n'est pas exhaustive d'un point de vue ingénierie réseau.
Sans avoir une prise directe sur les configurations des équipements, il est quasiment impossible pour un abonné de percevoir depuis son terminal les contraintes réseaux qui lui sont appliquées compte tenu des ajustements que permettent les équipementiers.
Pour simple contre exemple, la transparence aux traceroute pour les routeurs est tout à fait standard dans un coeur de réseau. Vous transitez par définition par plusieurs routeurs Orange et Free (domaines BGP différents sur l'interco) que vous ne verrez jamais apparaitre dans un simple traceroute. D'autre part, la QoS n'apportant aucune modification dans les paquets (simple gestion de file), vous ne pourrez pas non plus en déterminer l'origine.
Votre étude est intéressante, il est indéniable que l'un des deux opérateurs procède à du bridage mais elle ne permet pas en l'état d'incriminer free avec certitude.
Merci pour vos retours. J'ai modifié l'article en retirant la partie discutable, et en le complétant.
Merci pour vos retours. J'ai modifié l'article en retirant la partie discutable, et en le complétant.
Merci pour vos retours.
Après vérifications de vos retours (en partie juste, mais pas totalement), j'ai apportés quelques modifications en tenant compte.
Merci pour vos retours.
Après vérifications de vos retours (en partie juste, mais pas totalement), j'ai fais quelques modifications en tenant compte.
qu'est ce qui t'empeche de matcher les requetes HTTP sur extension par exemple ? et le les flagger avec un prio faible ?
Je ne comprends pas pourquoi tu te limite au L3 , les couches OSI ne sont pas étanches, les contenus des couches supérieurs sont encapsulés dans les couches inférieurs mais tu peux toujours en lire le contenu. (tant que ce n'est pas crypté ofc)
par ex : matcher touts les segments TCP qui contiennent "youtube" ou "mpeg" et marker cette session.
tu fais ensuite passer ces sessions par un qdisc pour limiter la BP : CBQ ou HTB voir même tbf ou red.
rien de plus simple...
Prenons en compte ton hypothèse. Quel intérêt pour Orange de mettre en place un tel processus (qui demande donc des paramétrages spécifiques et peut être même des équipements spécifique supplémentaires) alors qu'il facture notamment à la quantité de trafic consommé?
Car, tu l'auras remarqué, mon raisonnement ne repose pas uniquement sur les éléments techniques que j'ai relevé, qui effectivement seuls sont insuffisant.
A noter que je ne tire pas de conclusion définitive, bien au contraire, je laisse une part de doute sur le fait qu'Orange puisse mettre en place de son coté une QoS.
Je ne fais que dire qu'il est plus dans l'intérêt de Free (pour limiter le coût de l'itinérance et éviter la saturation du lien d'interconnexion sans pour autant devoir alourdir fortement la facture payée à Orange) de mettre en place une QoS aussi drastique que celle constaté, plutôt que dans celle d'Orange (qui facture une partie variable relative à la quantité de trafic consommé).
Cela ne reste qu'une hypothèse que je fais, je sais que certains cite ont cité mon billet en parlant de "preuve" ou de "démonstration", mais cela est une erreur de leur part, ce n'est aucunement une démonstration et encore moins une preuve. Je n'apporte ici que des éléments de réponse.
A chacun de se faire son opinion à partir de ceux-ci.
A noter que, comme je l'ai dit dans ma conclusion, je trouve que cette stratégie est intelligente de la part de Free (même si son succès fait qu'à certaines heures dans certains endroits très denses (notamment Paris), la connexion devient très difficile, voir inutilisable).
C'est une stratégie intelligente parce qu'elle permet à Free de limiter le coût de l'itinérance et que si aujourd'hui il y a de grosses difficulté parfois, plus le déploiement de son réseau propre avancera, moins cette QoS sera problématique sur l'itinérance (qui véhiculera de fait de moins en moins de trafic).
Evidement, Free s'expose au même risques que ce qu'il a subit en appliquant une stratégie tout à fait comparable sur l'IP/ADSL jouant également sur le fait qu'il dégroupait (et dégroupe toujours) de plus en plus de NRA.
Mais bon sur le fixe il n'a été condamné qu'à 100000 Euros d'amende pour cette pratique, c'est certainement une brindille par rapport à ce qu'il a économisé en facture de France Telecom/Orange sur l'IP/ADSL.
Et comme je l'ai dit, tant que le bilan recrutements-résiliations reste positif, pourquoi s'en priverait il. Et aux dernières nouvelles pour le moment ce bilan est positif pour Free Mobile.
Deux sujet:
je ne fais que corriger les erreurs quand je les lis : il est techniquement possible d'implémenter un bridage comme celui que nous subissons sur les equipements d'Orange. Les bricolages via tc/ebtables que je cite en exemple sont disponible sur tous les equipments de shaping des opérateurs nativement (en equivalent propriétaire ofc) et tu peux être certain que de tels equipements sont déja présents pour de multiples usages : internet à deux vitesse, P2P, clients business vs particuliers, DoS mitigation, etc. C'est builtin dans la plupart des FW et LB.
Ayant dit ca, je suis moi aussi de l'avis que le responsable est Free, OBS a largement la capacité disponible et c'est sans doute contraire à leur contrat. Je dois quand même faire remarquer qu'au final si les clients Free changent d'opérateur à cause du service plus que médiocre, c'est plus avantageux pour Orange que pour Free.
excellent post ! merci ! j'ai d'ailleurs reporté tout cela dans le forum UFC Que Choisir (en mentionant la source) pour ouvrir un débat
Salut à toutes et à tous !
J'ai EarthVPN et je peux me connecter à des serveurs de pleins de pays ainsi qu'en OpenVPN ou PPTP.
Quelqu'un pourrait me dire quel port et quel protocole utilisez-vous afin de vous connecter ?
Je n'ai pas une très bonne connexion, malgré le fait que je capte très bien en H+ une antenne Orange. J'ai essayé l'OpenVPN sur différents ports et dans différents pays mais c'est pas encore ça. Je tiens à préciser que ces serveurs VPN, testés sur ma connexion numericable fonctionnent très bien. Free arrive tout de même à filtrer !
Autre précision, quand je me connecte avec un VPN sur une antenne Free, tout se passe bien ;)
Enregistrer un commentaire