J'avais un peu zappé, mais je viens d'installer l'application et d'activer l'esim. Premiers tests très positifs, chez moi en intérieur : 500 Mb/s en down, 25 Mb/s en up.
J'ai au mieux 10 à 20 Mb.s dans les mêmes conditions chez Free mobile (avec quelques améliorations récemment, avant c'était plutôt 2 à 3 Mb/s) et Bouygues Telecom, avec deux abonnements qui sont aussi 5G.

P.S : Voici les copies d'écran des speedtests nPerf que j'avais faits, à quelques minutes d'intervalle (20 mn). Pour celui Free mobile, aucune surprise, c'est dans la moyenne de ce que j'obtiens d'habitude. Ce n'est pas forcément chez moi que c'est le plus important, parce que j'ai le WiFi, voir un autre test fait récemment (j'ai la Delta r1, avec WiFi 5, qui gère des canaux 5 GHz de 160 MHz, c'est bien la bande passante disponible qui compte le plus pour les débits). J'ai changé récemment de téléphone pour un Realme 16 pro+, nettement plus performant en WiFi que mon Samsung A54, où je plafonnais à 500 Mb/s. Mais il n'y a en tout cas, à cette localisation, pas photo entre Orange 5G et Free 5G. On verra plus tard, après d'autres tests, si je me laisse tenter par l'offre promotionnelle Hello 5G 120 Go à 14.99 €...

Salut Alain,

Quel modèle de smartphone utilises-tu ?

Le "bug" n'est-il pas tout simplement l'expiration de l'adresse IPv6 de la machine, parce que tu as utilisé une de ses adresses temporaires pour la règle de pare-feu ? Dans ce cas, la Livebox continue de rediriger du trafic vers une adresse qui n'est plus portée par aucun hôte.

Windows et Linux ont 3 modalités d'adressage IPv6 automatique :

• Adresse dynamique avec partie hôte aléatoire (RFC 4941)
• Adresse stable avec partie hôte aléatoire (RFC 7217)
• Adresse stable avec partie hôte personnalisée : attribut ip-token paramétrable avec iproute2 et une tâche cron, ou Network Manager.
• Adresse stable avec partie hôte constituée d'après l'adresse MAC (EUI-64)

Cette dernière méthode est aujourd'hui désactivée par défaut sauf dans les OS serveur Linux. Si du trafic entrant doit être initié vers la machine, il faut utiliser une des trois dernières selon la configuration de la machine mais je déconseille EUI-64.

$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp15s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:e0a:a09:xxxx:d31d:4920:f74e:6ab4/64 scope global temporary dynamic
       valid_lft 171130sec preferred_lft 84552sec
    inet6 2a01:e0a:a09:xxxx:df33:2260:acca:c6fd/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591802sec preferred_lft 604602sec
    inet6 fe80::7988:fd40:715e:852/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Il faut toujours utiliser une adresse qui ne porte pas les drapeaux temporary dynamic. Sous Windows, l'adresse stable est celle qui s'affiche devant "Adresse IPv6" que ce soit dans l'ancien ou le nouveau panneau de configuration, par opposition à "Adresse IPv6 temporaire". Mes serveurs ont tous l'EUI-64 désactivé, une IP statique et une ou plusieurs RFC4941 pour les connexions sortantes. Cependant, de toutes ces méthodes, une seule résiste aux changements de préfixe : l'utilisation d'ip-token. La partie hôte des adresses RFC 7217 change en même temps que le préfixe. Et si ça arrive, tu as une nouvelle adresse IPv6 à indiquer dans la Livebox pour rediriger le trafic. Mais, même à ça, je ne sais pas si la Livebox est suffisamment bien faite pour ne mettre à jour que la partie préfixe pour qu'en cas d'utilisation d'ip-token, le changement soit complètement transparent.

Un logiciel ou un driver à la noix "gamer" qui fout la mer**de

Non ce n'est pas un poblème matériel chez moi car j'ai le même souci sur 2 consoles + un pc testé sur 2 box + 1 box situé a 2 km de chez moi. le tout testé avec différent cables.

Je met ici une nouvelle capture peut être beaucoup plus parlante de test en udp sur 1.1.1.1
La connexion switch a partir du saut 4 elle passe de prs-b3-link.ip.twelve99.net à lag-101.ear6.paris1.level3.net.

Perso je n'ai rien compris.

Tu n'es pas le seul 

Voir reflexions ci-dessus, non ce n'est pas si simple 

Est-ce que j'ai dit que c'était parfait ? Non. Mais si déjà on n'ajoutait pas des contraintes aux contraintes, ça serait pas mal.  En levant les limitations côté GP, on aurait résolu je pense 90% des problèmes pour avoir un réseau qui marche avec une config avancée chez soi. Dans ma config actuelle, j'ai quasiment rien à faire, ça juste marche. Si je devais râler pour un truc ça serait mon préfixe qui change de temps en temps et qui casse mes config de certains serveurs (et encore sous Linux avec ip token ça m'évite les reconfig).

Côté entreprises, même sans limitations, oui, gérer plusieurs préfixes en cas de multi wan est casse tête même si on peut théoriquement diffuser plusieurs préfixes et choisir celui qui est prioritaire, l'autre prenant le relais lorsque ça tombe.  Si on veut vraiment rester sur un seul préfixe sans avoir un PI, le NPTv6 est à mon avis la solution la plus propre en gardant par exemple le préfixe courant et nater le/les préfixes de secours.