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

Le problème de congestion en soirée existe bel et bien, peut-être pas partout...
Moi je suis en adsl, dans le 31. En moyenne le débit dégringole franchement vers 17h30 (18h aujourd'hui) et à partir de 23h30 en général c'est comme si on avait remis un interrupteur sur "on" car tout repart plein pot (sauf que c'est l'heure d'aller se coucher, pour les gens honnêtes).

J'ai aussi contacté le support Free (twitter aujourd'hui encore) : dixit ["Actuellement je ne détecte pas d'anomalie sur la ligne ou les services. S'il en existe, elles ne sont pas détectables depuis les tests que je peux effectuer.\n Si le dysfonctionnement que vous décrivez ne cesse pas, je vous invite à contacter le 3244."]
Forcément, un test à 15h30... Mais comment avoir quelqu'un du support pour un test à 21h ? Bref.

Pour ma part, c'est surf lent (ça tombe parfois à 1mbps mesuré), diablo III injouable avec IP 213.228.9.254 à 100% de packet lost (MRT) (et hier soir à 23h30 c'est revenu à 0% lost).

Tous mes voisins (résidence) chez Free ont ces lenteurs, la télé qui fige et reprend mais... à entendre le support, tout va bien.

Un graph mis à jour automatiquement :
https://priv.lokanova.com/metro/graph.png

Bonjour Thibault,

Je vous remercie pour la réponse.

L'aspect "jeu" n'est qu'une partie du problème : le graph en question est un speedtest (cli, sous debian) et montre donc, à défaut d'être rigoureux puisque non croisé, une tendance franche de perte de débit.

Le problème étant que la plage horaire concernée est en dehors des heures où le support est joignable (enfin, il me semble) et donc c'est le serpent qui se mord la queue : on n'a rien constaté.
Encore une fois, je conviens que dev.freebox n'est pas le lieu pour ça mais... en réalité, on n'a de lieu nulle part pour une prise en compte précise du phénomène.

Bonjour et merci pour cette réponse rapide.

Comme le signale @Lat les problèmes nous concernant sont systématique a partir de 21h j'ai une monté progressive de perte de paquet sur l'ensemble d'internet (8.8.8.8., free.fr, serveur shadow, lemonde.fr etc...) pour arriver a 5% de perte vers 22h00 et ça décroisse aussi progressivement jusqu'a 23h ou je tombe a 0,01%.

Je pourrais vous montrer mes graphs c'est impressionnant la régularité de mon problème.

Merci pour vos lumières.

Cdt.

@Thibaut (pardon pour le l excédentaire au post précédent)

En espérant que la mac affiché dans l'appli android soit la bonne : 34:27:92:61:76:d2

Merci à vous pour cette proposition hors horaires !!

@Thibaut,

Pour apporter un complément au graph issu de speedtest réalisés en série, voici quelques MTR réalisés ce soir vers différentes cibles :
J'attire l'attention sur le 3e saut, systématiquement en défaut ! Ce 3e hop met d'ailleurs du temps à s'afficher (voir capture prise avant où il est juste affiché avec des "???").
C'était comme ça hier soir, c'est comme ça les autres soirs aussi.

Je n'insère pas les images en balise image, pour ne pas casser la mise en page du fil.

1) Vers online (dedibox)
http://lokanova.free.fr/upload/files/2020-03-03_21-07-24.png

2) Vers google.co.uk
http://lokanova.free.fr/upload/files/2020-03-03_21-15-38.png

3) Vers une IP blizzard fournie en FAQ de l'éditeur pour debug des pb de connexion en Europe :
Avant que le 3e saut apparaisse
http://lokanova.free.fr/upload/files/2020-03-03_20-40-24.png Dès que le 3e saut s'affiche (notez que ses stats totales sont qd même calculées
http://lokanova.free.fr/upload/files/2020-03-03_20-47-55.png

Bonne soirée

Bonjour,

Hier soir j'ai encore été confronté à cette monté de perte de paquets vers Shadow et Google (surement d'autres service mais j'ai accentué mais test sur c'est deux services).

J'ai commencé a utilisé Shadow vers 18h30 ou je n'avais aucun problème jusqu'a 21h05 ou la situation à commencé a se dégrader progressivement avec des pertes de paquet ne dépassant pas 2%.

Le moment le plus critique a commencé vers 22h05 ou j'avais 5% de perte de paquets.

Traceroute vers Shadow à 22h07 :

WinMTR vers DNS Go85.190.66.254 à 22h10 :

Graphique de Shadow à 22h26

WinMTR vers Shadow à 22h32 - IP 85.190.66.254

23h00 La situation commence a s'améliorer

Traceroute vers Shadow a 23h06

Graphique Shadow a 23h13 ~ 0.3 % de perte de paquets

Graphique Shadow de 22h45 à 23h15 (mise en évidence de la décroissance des pertes de paquets sur 30 minutes)

WinMTR vers DNS google à 23h35 - 8.8.8.8

Graphique Shadow à 23h30 - 0,1% de perte de paquets - (vous remarquez que le ping est plus stable)

Bonsoir,

Ce soir est de nouveau un bel exemple de ma connexion qui perte toujours autant de paquets (+10 % ce soir)
Ça a commencé à 21h00 avec un pique a 22h00 ou la ça devient complètement injouable !

Début des pertes - 1% 21h00

5% 22h00

+ 10% 22h14

Ping vers Shadow

Espérons que Thibaut ait pu constater quelque chose hier soir.

Je suis également disponible si test complémentaire à réaliser.

Bonjour Thibaut,

Pouvez-vous me rajouter a vos tests si je vous fournis mon adresse Mac ?

Merci pour votre retour,

Bien cordialement

Aurélien

@Thibault,

MAC : 70:FC:8F:40:5D:09

C'est très sympa de votre part et je vous en remercie, mais comme je vous le disais plus haut le SAV ne prend pas mes demandes en compte malheureusement, j'ai essayé d'appelé 6 fois le support et des que je parles de perte de paquets on me répond que j'ai internet donc ça fonctionne ...

Merci encore

Aurélien

@Thibault oui vous avez raison mais vu que je n'ai pas de problème de débit ... :)

Je n'en peux plus, je sature.

Pas moins de rester en ligne sur un DIII plus de 30 secondes, un téléchargement d'image raspbian qui plafonne à 30Ko/s alors qu'au même moment sur une dedibox il file à 16Mo/s. (ça c'était hier ~23h00 / 23h30)

Au secours ; j'en suis rendu à un point où je préfère encore payer mes 10 balles par mois de delta player et la remiser dans un placard et changer de FAI.

Petit check du jour :
http://lokanova.free.fr/upload/files/?filesTransferred=rlb.png

Petit jeu des 9 différences :

MTR 3.3.20 20:47:
http://lokanova.free.fr/upload/files/2020-03-03_20-47-55.png

MTR 7.3.20 10:26 :
http://lokanova.free.fr/upload/files/2020-03-07_10-26-15.png

ha, au fait, le week-end, c'est à peu-prêt 10h30 pour le début des hostilités (je vous laisse imaginer durant les vacances scolaires).
Aujourd'hui a d'ailleurs été le pire (croix - centrée dans carré) pour différents horaires.

https://priv.lokanova.com/metro/graph.png

J'ai passé encore un week-end bien pourri avec ces problèmes de pertes de paquets ...
Sincèrement je ne sais plus quoi faire le support technique m'amusent en me disant qu'un technicien de niveau 2 va m'appeler (ça fait une semaine que j'attends toujours..)

Je vais faire partir un courrier avec AR ce jour pour me plaindre de leurs non réponse. C'est quand même dingue je n'ai aucun ticket d'ouvert dans mon interface et a chaque fois que j’appelle le support il ne voit aucune trace de mes précédents appels.

J'ai regardé pour passer chez Orange mais je suis encore engagé chez Free et ça va me coûter plus de 300 € pour les quitter mais j'en peux plus de ne pas pouvoir me servir d'internet quand j'en ai le plus besoin.

Aurélien

peut-être que par là ?
https://twitter.com/Schbe_BruSch/status/1236043037823905798?s=20

@Lat J'ai commencé a contacter 60 millions de conso mais visiblement il faut d'abord commencer par le médiateur des télécoms... et pour pouvoir faire appel au médiateur il faut commencer par envoyer une lettre en AR grrrr !

@Thibault Merci pour votre retour. C'est bien un problème de routage dès que je passe sur la route secondaire (ce qui intervient de 21h30 à 23h le soir et le week-end) j'ai des pertes de paquets.

Mon souci c'est que niveau filtrage téléphonique au 32 44 c'est impossible de discuter, la dernière personne que j'ai eu m'a quand même dit que mon problème venait mon Wifi alors que j'avais précisé au préalable que j'étais en câble RJ45 !!!

J'aimerai bien pouvoir discuter avec une personne du réseau qui comprendrait surement très vite mon problème.

Cordialement,

Aurélien

Thibaut, merci pour ce retour... et touchons du bois !

Bonne soirée.

Bonsoir,

Bon plus le temps passe et plus je comprends ce qui ce passe. Le soir de 21h/21h30 jusqu’à 23h je passe par une route secondaire (chez Free) et visiblement cette route à un équipement qui est pas en forme : p11-crs16-1-be1114.intf.routers.proxad.net
J'ai vu sur d'autre forum que cette équipement a déjà eu exactement le même problème mais ça date de 2016/2018.

Si seulement je pouvais expliquer ça avec quelqu'un de chez Free (réseau)... mais toujours impossible d'avoir quelqu'un qui m'écoute au support !!!

J'aimerai tellement pouvoir me servir de mon Shadow-PC le soir !!!

Aurélien

Vous c'est p11-crs16-1-be1114.intf.routers.proxad.net, moi c'est un autre... ce sont des points de concentration qui saturent en périodes de pointe.

Contrairement à ceci :
http://lokanova.free.fr/upload/files/rlb.png

Voilà comment ça se comporte en journée (à l'instant ~13h00) quand on n'est __pas en pointe__ :

deb10 (192.168.0)                                                                                         2020-03-12T13:07:00+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                              Packets               Pings
 Host                                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.0.254                                                                            0.0%   316    0.3   0.2   0.2   0.6   0.1
 2. c2s31-2-83-152-89-254.fbx.proxad.net                                                     0.0%   316   16.0  15.9  15.2  16.8   0.3
 3. ???
 4. 194.149.170.121                                                                          0.3%   315   27.0  27.3  26.6  29.8   0.4
 5. amsterdam-9k-1-be1004.intf.routers.proxad.net                                            0.0%   315   40.9  41.0  40.2  43.6   0.5
 6. 80.249.208.83                                                                            0.0%   315   41.7  47.8  40.6 405.1  23.6
 7. ae1-br02-eqam1.as57976.net                                                               0.0%   315   42.2  45.1  40.7 129.9  12.0
 8. 137.221.78.83                                                                            0.0%   315   41.1  43.4  40.4 107.6   9.5
 9. 185.60.112.157                                                                           0.0%   315   43.4  41.8  40.7  48.9   1.0

Le saut 3 met tjrs un temps bête à donner son ip mais ça montre très bien le phénomène : pas de perte.

ça commence... magnifie que saut 7 -_-'

deb10 (192.168.0)                                                     2020-03-12T17:58:40+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                          Packets               Pings
 Host                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.0.254                                        0.0%    70    0.3   0.3   0.2   0.4   0.0
 2. 83.152.89.254                                        0.0%    70   15.9  20.2  15.6 113.2  14.9
 3. 213.228.9.254                                       59.4%    69   22.4  22.5  19.3  26.9   1.5
 4. 194.149.170.121                                      4.3%    69   32.7  33.5  28.2  57.1   4.7
 5. 194.149.163.50                                       5.8%    69   45.4  49.2  41.6 133.4  13.2
 6. 80.249.208.83                                        4.3%    69   46.3  52.0  42.0 111.2  13.1
 7. 137.221.78.35                                       89.7%    69  8906. 3061.  45.7 8906. 3639.
 8. 137.221.78.83                                       10.1%    69   46.6  47.8  42.2  91.3   6.5
 9. 185.60.112.157                                      11.6%    69   50.9  46.3  41.8  63.8   2.9

(magnifique le saut)

Salut Lat,

D'après ce que j'ai compris c'est que le routeur est trop occupé pour répondre au ping (qui n'est pas une priorité pour lui) donc si j’interprète tes résultats sur ton traceroute tu as sur l'ensemble 11,6% de pertes de paquets sur l'adresse 185.60.112.157

C'est quand même dingue free a un réseau complètement obsolète pour avoir autant de perte.

J'en peux plus je peux rien faire d'internet !

C'est bien cela, nous sommes face à des noeuds (chez moi le saut 3) qui saturent et donc qui font du tri sur les informations à traiter.
Quand il daigne traiter, la latence n'est pas crade

Enfin, à ce niveau là (60% à 18h00 - 90% en ce moment même), ça n'est plus du tri c'est de la destruction de masse.
Malgré que le saut 7 (ip qui n'appartient pas à Free) semble être en difficulté aujourd'hui j'ai donné le tableau : tout n'est pas toujours entièrement dû à l'infra Free.

En voici d'autres en cours en ce moment :

Vers la même ip blizzard

                                                           Packets               Pings
Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                              0.0%   786    1.2   1.5   0.7   5.9   0.8
 2. c2s31-2-83-152-89-254.fbx.proxad.net                  0.5%   786   19.0  18.8  16.0  49.4   3.7
 3. 213.228.9.254                                        91.2%   786   25.1  27.5  22.2  54.6   6.2
 4. 194.149.170.121                                      17.3%   785   34.3  36.3  32.2 112.6   8.1
 5. amsterdam-9k-1-be1004.intf.routers.proxad.net        15.5%   785   48.6  49.6  44.8 114.6   6.6
 6. 80.249.208.83                                        15.7%   785   49.0  53.9  44.5 796.2  30.8
 7. ae1-br02-eqam1.as57976.net                           17.7%   785   48.7 1432.  45.9 8164. 1865.
 8. 137.221.78.83                                        17.3%   785   48.4  51.2  45.1 114.1   9.6
 9. 185.60.112.157                                       14.8%   785   50.0  49.9  45.4 114.5   5.8

Vers un dns google

                                                           Packets               Pings
 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                              1.4%   278    1.2   1.6   0.7   6.0   0.8
 2. c2s31-2-83-152-89-254.fbx.proxad.net                  0.7%   278   34.8  19.2  15.8  68.1   4.1
 3. 213.228.9.254                                        75.5%   278   24.6  26.8  21.7  83.0   8.7
 4. 194.149.170.121                                      24.5%   278   49.5  37.0  32.5 109.7   8.7
 5. 194.149.166.58                                       18.1%   277   49.8  36.2  32.0 114.4   8.7
 6. 72.14.221.62                                         12.3%   277   45.0  35.6  32.6  65.1   3.9
 7. 108.170.244.161                                      11.9%   277   49.7  35.8  32.1 105.7   5.9
 8. 108.170.232.125                                      13.0%   277   46.4  36.2  32.5 107.0   7.4
 9. dns.google                                           14.1%   277   51.9  36.1  32.4 110.6   8.0

Mais si je comprends bien celui de 19h c'est bien Free le responsable avec le saut 3. 213.228.9.254 59.4% c'est lui que te dégrade complètement ta connexion jusqu'a chez Blizard. Ce que je veux dire c'est que c'est le seul responsable des 11,6 % de pertes que tu as a la fin ! Si je dis une connerie corrige moi :)

Il faut lire un MTR en prenant en compte l'ensemble des sauts (hops).
Si le saut 3 est le seul à avoir des pertes de paquets et que tout le reste du tableau est correct on peut simplement se trouver face à un routeur sur lequel l'opérateur a volontairement choisi de limiter la charge ICMP (donc les réponses).

En l'occurence, mon tableau de 13h00 hier montre une situation saine (même si le sauts 3 pas encore affiché est à 80% de "pertes")
Et mon tableau de 17h58 montre que la situation se dégrade globalement.

Mes deux derniers tableaux montrent une situation dégradée vers deux cibles différentes avec des pourcentages similaires après le saut 3 et, pour l'ip cible blizzard, un saut qui leur appartient complètement dans les choux en terme de latence.

Un peu de lecture vulgarisée : https://wiki.evolix.org/HowtoMTR

Bonjour,

Egalement utilisateur de Shadow, je confirme des pertes de paquets sévères selon les horaires de la journée (souvent 18h ou en ce moment-même 22h).

Le jeu en streaming étant extrêmement gourmand en ressources (du haut débit en temps réel, on ne parle plus de vidéos YouTube avec buffer... qui elles-même posaient problème sur le réseau Free il y a quelques années), et ce mode d'utilisation ayant le vent en poupe, peut-être Free devrait-il commencer à se rapprocher de Shadow (et des autres services type Stadia) pour échanger des statistiques et tirer des conclusions vis-à-vis du réseau.

Bien cordialement.

Préparons-nous à souffrir même en journée la semaine puisque tous les étudiants sont @home.

Bonsoir,

En simmultané :

MTR du dessus, source dedibox
MTR du dessous, source adsl domicile

Il serait plus que temps que ça "bouge". Routage, peering ou tout ce qu'on veut d'autre en réalité ça n'est pas notre pb...

Re-bonjour,

J'ai envoyé un message à Shadow pour leur rapporter le problème, et notamment l'existence de ce thread. Ils "savent" des problèmes avec Free, sont notamment en contact permanent avec tous les opérateurs pour que tout marche pour le mieux, mais bien sûr ne peuvent rien faire pour des problèmes réseau hors de leur portée.

Dans notre cas, nous ne pouvons donc rien faire d'autre que d'attendre que Free prenne les choses en main.

Cordialement.

Dans l'impossibilité d'avoir quelqu'un au 3244, je me suis résolu à faire un face2free... en 3G Orange car avec l'adsl dans cet état, ça coupe !
Je lui ai montré mes écrans (graph, mtr, téléchargement d'une iso debian à 45Ko/s, un test de débit réalisé en live, etc.) et lui était complètement "dans un autre monde" avec ce qu'il voyait de son côté : aucun pb sur la ligne, débit correct...

Résultat, j'vous l'donne Emile : il vous faudrait appeler au 3244 pour avoir le support niveau 2 (aka "premium support") car vous avez une Delta et on n'a pas accès à tout.
Il ne pouvait pas lui-même me transférer pas plus qu'il ne peut "appeler à ce qu'on m'appelle" ("je peux l'inscrire au dossier mais ils vont mettre du temps").

Bon, sauf qu'en appelant le 3244, ça dit (robot) : nous vous proposons de vous rendre sur www.free.fr/3244 Tu te dis "pas grave, proposition rejetée, je reste en ligne". Sauf que ça raccroche.

(je précise qu'il était très correct, je ne tape en rien sur lui-même)

Bonjour,

Je viens d'écrire ce thread, qui pourrait expliquer le problème : https://dev.freebox.fr/bugs/task/30323

Cordialement.

Bonsoir,
Ma 4G est décochée depuis des semaines :/

Ce serait le pied de lire une intervention "d'un officiel" à ce sujet...

Ma box vient de perdre la synchro, de faire de multiples passages entre étape 2, 3 et 4 pour finalement à nouveau accrocher et... tadam, débit au max oO
Je ne comprends pas ce qui s'est passé, d'autant que si je teste quelques traceroute qui mettaient en évidence des pertes énormes de paquets ceux-ci n'ont pas changé (même route) MAIS sont parfaitement clean en terme de % loss.

A voir si ça tient dans la durée (on va pas jubiler trop vite) mais ça semble bien montrer qu'il y avait un problème connu "quelque part".

Cf le graph à 21h00 par ailleurs : http://lokanova.Free.fr/upload/files/spot21h.png (live https://priv.lokanova.com/metro/graph.png )

Oui Thibaut, les évènements qui ont suivi laissent penser à une maintenance matérielle car les routes après resynchro ont mis quelque temps à retrouver un état normal (ça sentait clairement l'auto apprentissage suite à la perte d'un noeud)

Le graph "live" que je lie régulièrement montre clairement une stabilité à présent (le creux de ce jour correspond à une période "télé allumée" en adsl et non en tnt)

Pour ne pas paraître incohérent avec mon message de la veille :

- désynchro / resynchro
- routes immédiatement ok (et message de ma part)
- quelques minutes plus tard perte des routes habituelles (et re %loss à gogo) et passages par des noeuds improbables.
- plus tard mais j'ai pas de timestamp précis (je jouais en ligne via vpn pour éviter les routes en émoi), retour des routes habituelles.

Je laisse ma mesure tourner encore quelques temps sans agrégation et puis je tenterai de la réactiver afin de voir si les soucis de ce côté là s'en trouvent arrangés.

Bonjour @Thibaut et l'équipe,

Je mets le doigt sur un comportement qui existe lorsque l'agrégation est activée :

• Si transfert ipv6 : pas d'agré comme prévu et débit xDSL à saturation de la ligne.
• Si transfert ipv4 : la box alterne entre l'xDSL et la 4G mais pas les deux agrégés (700Mhz ou 1800Mhz)

Illustration en wget sur poste du lan (comportement identique sur speedtest ip4 vs ip6 dans un navigateur) :

wget -4 -r http://test-debit.free.fr/32768.rnd
--2020-04-19 14:04:28--  http://test-debit.free.fr/32768.rnd
Résolution de test-debit.free.fr (test-debit.free.fr)… 212.27.42.153
Connexion à test-debit.free.fr (test-debit.free.fr)|212.27.42.153|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 33554432 (32M)
Sauvegarde en : « test-debit.free.fr/32768.rnd »

test-debit.free.fr/32768.rnd    100%[====================================================>]  32,00M   552KB/s    ds 46s     

2020-04-19 14:05:14 (715 KB/s) — « test-debit.free.fr/32768.rnd » sauvegardé [33554432/33554432]

Terminé — 2020-04-19 14:05:14 —
Temps total effectif : 46s
Téléchargés : 1 fichiers, 32M en 46s (715 KB/s)



wget -r http://test-debit.free.fr/32768.rnd
--2020-04-19 14:05:59--  http://test-debit.free.fr/32768.rnd
Résolution de test-debit.free.fr (test-debit.free.fr)… 2a01:e0c:1:1598::3, 212.27.42.153
Connexion à test-debit.free.fr (test-debit.free.fr)|2a01:e0c:1:1598::3|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 33554432 (32M)
Sauvegarde en : « test-debit.free.fr/32768.rnd »

test-debit.free.fr/32768.rnd    100%[====================================================>]  32,00M  1,57MB/s    ds 20s     

2020-04-19 14:06:20 (1,57 MB/s) — « test-debit.free.fr/32768.rnd » sauvegardé [33554432/33554432]

Terminé — 2020-04-19 14:06:20 —
Temps total effectif : 21s
Téléchargés : 1 fichiers, 32M en 20s (1,57 MB/s)

Le wget en -4 affiche un débit moyen de 715Ko/s (et dernier débit instantané à 550Ko/s), notez toutefois qu'en phase 4G ça tombe jusqu'à 30Ko/s

→ Contrairement à ce qui est attendu techniquement (et commercialement mais c'est un autre sujet), on a un transfert plus lent en agrégation qu'en xDSL pur.
→ Vous m'aviez expliqué quelque part que l'agrégation ne joue pas pour les VM hébergées par la box, hors :

1. Lorsque l'agrégation n'est pas active, des speedtest-cli sur VM montrent une courbe DL extrêmement régulière :
   https://priv.lokanova.com/metro/okfreeno4g.png
2. Lorsque l'agrégation est active, des speedtest-cli sur VM montrent une courbe (bleue) plus variable :
   https://priv.lokanova.com/metro/okfree4g.png
3. Hors contexte "problème" pourquoi le ping (même sur VM) ip6 se trouve-t-il amélioré par rapport à ip4 en mode agrégation active ?

Bon, tout ça commence à radicalement changer de sujet, l'initial étant éteint. Si vous souhaitez que je formule un nouveau billet je m'y emploierai ;)

Cordialement,

Le comportement constaté semble être le signe annonciateur d'une perte totale de fonctionnement correct avec agrégation activée.
Cf. https://dev.freebox.fr/bugs/task/29862 , mon dernier commentaire.

Bref. Là pour le coup je vais en revenir au sujet du commercial... Bien entendu, ça n'est pas le canal prévu pour ça donc je me limite à cette phrase.

Bonne continuation.