[Xfreerdp] affichage d'images lag

[benjarobin]

Je ne sais pas quoi te dire, abel99 à 100% raison (et il dit exactement la même chose que moi). Et comme ces tests tu ne pourras pas les faire, tu ne pourras jamais conclure !
Ce n'est d'ailleurs très certainement pas un bridage en particulier d'openVPN, comme déjà expliqué...
Et arrête de bluffer dans tes messages, c'est lourd : Je ne crois pas une seule seconde que tu as payé un huissier de justice pour cela !
Si tu avais de bien meilleurs connaissance en réseau, et un accès complet au réseau de ton travail, alors oui on aurais pu essayer de trouver la cause, mais c'est très difficile, et cela demande beaucoup de temps. Rien que pour trouver pourquoi orange me bridait mon flux SSH (alors qu'au final ce n'était absolument pas en rapport au flux SSH), cela m'a pris plus de 2 mois pour comprendre (après je ne cherchais pas au bon endroit : Le réseau c'est très compliqué)

[benjibasson]

Mais pourtant les test times curl wget mis en confrontation avec nperf prouve que le problème varie énormément juste en changeant d'opérateur.

En tout cas j'irai jusqu'au bout et j'irai au tribunal d'instance ( ex juridiction de proximité) avec mon PC et mon oppo qui est double sim, et le juge apreciera mes preuves d'accusation contre free.
Et là je ne bluffe pas. J'ai déjà gagné contre canon pour une dénonciation de garantie pour une oxydation non chiffrable ni appréciable
Donc je gagnerai contre free qui fait du bridage chiffrable et qualifiable.

Et il me semble que si ca venait pas de free mobile tu aurais trouvé une solution pour toi tout en restant chez free.
De plus tu l'as dit

LOL... Free est l'opérateur qui fait le plus de QoS... Bref il ne faut pas se fier à la communication "officiel"

C'était un cri du cœur. Vraiment.

[benjarobin]

Bonne chance, tu as aucune chance, surtout que tu n'as pas de connaissance technique. Encore ce n'est peut être pas un problème de bridage, mais juste de peering. C'est pour cela que abel99 t'a posé et demandé de faire des tests supplémentaires (mais que tu ne peux pas faire). Note : Un problème de peering n'est pas forcément la responsabilité de free.
Je ne sais plus trop pourquoi je réponds : Peux être que je n'ai pas envi que tu perdes ton temps et ton argent (et aussi te ridiculiser au passage). Bonne chance pour prouver cela : https://www.vie-publique.fr/eclairage/1 ... les-enjeux

[benjibasson]

On fait comment pour faire du nperf ou bien faire un wget 8.8.8.8 en passant par tun0 au lieu de eth0 ?

[benjarobin]

Ce que tu demandes n'a aucun sens. Ton OpenVPN fournit un tunnel entre ton entreprise et ton PC : Il met à disposition le réseau local de ton entreprise à ton PC. Ce tunnel (bien que cela pourrait être possible) ne fournit pas Internet (contrairement à certain service de VPN mais ce n'est pas le même but...), le trafic Internet passe bien toujours par eth0 dans ton cas.

[benjibasson]

Donc techniquement je peux faire le test demandé le jour où je deviens responsable informatique. ( C'est à dire jamais)

Dans les faits je comprends que si je veux rester chez free mobile ou sfr il faut que j'apprenne un max sur le réseau, et bidouiller pour pouvoir faire du télétravail. Parce que ca passe par 20801 et 20815.
Il faut que je me débrouille même si le problème est entre une installation appartement à l'opérateur et le serveur du tunnel vpn de mon boulot
Alors que chez Bouygues ou orange j'ai le droit d'être noob et le télétravail fonctionne tout seul de manière fluide comme un grand. Juste parce que ca passe par une antenne 20810 ou 20820
=> Pas normal

En tout cas si ça fonctionne fluide depuis orange/youprice c'est que le problème vient ni de mon matériel, ni de la config de mon PC
Et côté boulot ni du matériel, box, config de ma boîte, ni de la fibre ou boucle locale de ma boîte
L'apn et la sim j'en doute: soit tout fonctionne soit tout est coupé.
Faudrait qu'on m'explique d'où ca peut venir si le coupable n'est ni une infrastructure de free mobile, ni la politique free mobile
Dans le changement de trajectoire: quelle est la différence qui n'appartient ni à orange mobile ni à free mobile ?

[benjarobin]

Donc techniquement je peux faire le test demandé le jour où je deviens responsable informatique. ( C'est à dire jamais)

Tu n'as pas forcément compris le test qui devrait être réalisé, mais cela ne change rien, tu ne pourras pas le faire

... Alors que chez Bouygues ou orange j'ai le droit d'être noob et le télétravail fonctionne tout seul de manière fluide comme un grand. ... => Pas normal

Je n'ai jamais dis que c'était normal, mais plutôt que c'était une perte de temps. Aujourd'hui je suis pragmatique, si cela ne fonctionne pas et que je ne peux rien y faire, je change d'opérateur. Bien que je serais très curieux de savoir où est le bridage (mais via message interposé c'est impossible, et ce qu'il faudrait faire, je ne suis pas sûr que ton responsable informatique soit bien d'accord)

Faudrait qu'on m'explique d'où ca peut venir si le coupable n'est ni une infrastructure de free mobile, ni la politique free mobile
Dans le changement de trajectoire: quelle est la différence qui n'appartient ni à orange mobile ni à free mobile ?

Je dirais juste que pour aller d'un point A vers un point B, en fonction de l'opérateur tu ne prends pas forcément le même chemin (déjà le point A de départ n'est pas le même). Et en fonction du chemin emprunté, car la route a été configuré ainsi, ce n'est pas forcément le problème de Free. Ta boxe ne te connectes pas directement à "Internet", c'est un peu plus compliqué que cela, en fonction de la destination tu as des interconnexions entre différents réseaux (et des fois cette interconnexion est complètement saturé : Je me rappel il y a 10 ans chez Free l'interconnexion pour traverser l'atlantique via Cogent était très limité). Bref, le sujet est très complexe. Mais cela peut être aussi simple qu'une detection de type de flux et bridage de ce dernier (mais j'ai un petit doute que cela soit cela). C'est très très difficile de savoir...

Quelques liens car je suis curieux :
- https://www.arcep.fr/demarches-et-servi ... obile.html
- https://lafibre.info/free-mobile/ipv6-free-mobile/168/
- https://lafibre.info/free-mobile/ipv6-free-mobile/492/

[benjibasson]

J'étais déjà en ipv6 au début. Mais comme j'ai entendu que l'ipv6 peut poser problème et que mon nperf était faible en upload même sur Lyon, je l'ai désactivé sur Android et mon espace abonné. Sans différence.

Sur la route c'est bien free qui choisit le chemin emprunté pour aller de mon téléphone à internet/tunnel. Surtout pour un trajet nationale France France. ( Ma boîte est sur une box française )

Ensuite la traversée de l'Atlantique c'est bien un tronc commun quelque soit les 4 opérateurs, quelque soit l'offre fixe ou mobile ? Quelques soit la connexion par boucle locale cuivrée ou par l'optique?

Pour finir quand y avait le bridage de YouTube par free, c'était pour une raison purement administratif suite au conflit entre free et Google. Pas une question de route qui supportait plus de traffic. Un peu comme l'autoroute les premiers jours de gilets jaunes

[benjarobin]

Sur la route c'est bien free qui choisit le chemin emprunté pour aller de mon téléphone à internet/tunnel. Surtout pour un trajet nationale France France. ( Ma boîte est sur une box française )

Free ne maîtrise qu'une partie de la route, la porte de sortie de son réseau !
Et techniquement le chemin de retour n'est pas forcément le même, et ce n'est pas forcément le choix de Free.

Ensuite la traversée de l'Atlantique c'est bien un tronc commun quelque soit les 4 opérateurs, quelque soit l'offre fixe ou mobile ? Quelques soit la connexion par boucle locale cuivrée ou par l'optique?

Alors oui la fibre c'est la même, mais c'est un peu plus complexe que cela, il y a le Peering / Transit (https://fr.wikipedia.org/wiki/Peering) Et au final c'est une histoire d'argent : Si par exemple pour orange il y a autant de débit en Tx comme en Rx, le coût du peering est null. S'il y a une asymétrie, il faut payer, bref...

Pour finir quand y avait le bridage de YouTube par free, c'était pour une raison purement administratif suite au conflit entre free et Google. Pas une question de route qui supportait plus de traffic.

Oui, Free bridait volontairement, ce n'était pas pour une raison "administrative", de mémoire c'était afin de faire pression sur Google afin que Google installe à ses frais des serveurs de cache dans le réseau de Free (afin de réduire les problèmes de Peering), j'ai un doute sur l'historique, il faudrait faire des recherches, la flemme...

Note : Je ne cherches pas à défendre qui que ce soit. Le problème est compliqué, oui cela fini souvent par une histoire d'argent...

Note 2 : Bien que je me débrouille bien en réseau, je reste un "débutant" dans ce monde très complexe.

[laurent85]

+1 benjarobin
Tu ne veux pas entendre benjibasson que la cause n'est pas nécessairement chez free. Ton raisonnement ne tient pas la route même d'un point de vue de béotien sans compétences techniques. J'explique pourquoi.

Avec ton téléphone et en tant qu'utilisateur lambda tu observes une différence de débit suivant l'opérateur mobile dans l'utilisation d'une liaison vpn avec ta boite.

Et tu en déduis que c'est free qui bride. Pourquoi cette conclusion ? Pourquoi tu ne concluerais pas que c'est l'opérateur de la box qui bride freemobile ? Il y a 2 opérateurs, c'est l'un ou l'autre et rien ne te permet de conclure sur la responsabilité de l'un plutôt que l'autre.

Les causes peuvent être multiples, benjarobin l'a exposé dans le détail. Ce qui est certain tu ne peux rien conclure concernant la responsabilité, tu peux juste observer un débit insuffisant pour ton utilisation.

Tu as trouvé une solution au problème en changeant d'opérateur, c'est la bonne décision à prendre. Le juridique dans ce cas n'a aucun sens. Et puis on s'éloigne du sujet Archlinux.

[benjarobin]

Le juridique dans ce cas n'a aucun sens. Et puis on s'éloigne du sujet Archlinux.

J'ai peur aussi que l'on tourne en rond, si tu veux vraiment discuter de ce sujet (bien que je trouve que c'est dans tous les cas une perte de temps), je te conseil vivement ce forum https://lafibre.info/freemobile/, il contient des personnes avec bien plus d'expertise, c'est leur spécialité. Nous notre spécialité c'est Arch Linux. Note si tu crées un sujet là bas, n'hésite pas à mettre le lien ici, cela peut toujours être intéressant.

[benjibasson]

Bonjour
J'ai créé le sujet ici
https://lafibre.info/freemobile-inciden ... msg1015318

Salutations

[benjibasson]

Bonjour,
Mon responsable informatique vient de me confirmer que le serveur openvpn accepte udp et tcp. mais dans le fichier de config, quand je remplace proto tcp par proto udp ça ne se connecte pas et fait un message d'erreur sur le handshacking

Code : Tout sélectionner

2023-05-11 10:23:00 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-05-11 10:23:00 TLS Error: TLS handshake failed
2023-05-11 10:23:00 SIGUSR1[soft,tls-error] received, process restarting
2023-05-11 10:23:00 Restart pause, 5 second(s)
2023-05-11 10:23:05 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-05-11 10:23:05 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:443
2023-05-11 10:23:05 Socket Buffers: R=[212992->212992] S=[212992->212992]
2023-05-11 10:23:05 UDP link local: (not bound)
2023-05-11 10:23:05 UDP link remote: [AF_INET]x.x.x.x:443
2023-05-11 10:24:05 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-05-11 10:24:05 TLS Error: TLS handshake failed
2023-05-11 10:24:05 SIGUSR1[soft,tls-error] received, process restarting
2023-05-11 10:24:05 Restart pause, 5 second(s)
2023-05-11 10:24:10 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-05-11 10:24:11 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:443
2023-05-11 10:24:11 Socket Buffers: R=[212992->212992] S=[212992->212992]
2023-05-11 10:24:11 UDP link local: (not bound)
2023-05-11 10:24:11 UDP link remote: [AF_INET]x.x.x.x:443
2023-05-11 10:25:11 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-05-11 10:25:11 TLS Error: TLS handshake failed
2023-05-11 10:25:11 SIGUSR1[soft,tls-error] received, process restarting
2023-05-11 10:25:11 Restart pause, 5 second(s)
2023-05-11 10:25:16 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-05-11 10:25:16 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:443
2023-05-11 10:25:16 Socket Buffers: R=[212992->212992] S=[212992->212992]
2023-05-11 10:25:16 UDP link local: (not bound)
2023-05-11 10:25:16 UDP link remote: [AF_INET]x.x.x.x:443
2023-05-11 10:26:16 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-05-11 10:26:16 TLS Error: TLS handshake failed
2023-05-11 10:26:16 SIGUSR1[soft,tls-error] received, process restarting
2023-05-11 10:26:16 Restart pause, 5 second(s)
2023-05-11 10:26:21 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-05-11 10:26:21 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:443
2023-05-11 10:26:21 Socket Buffers: R=[212992->212992] S=[212992->212992]
2023-05-11 10:26:21 UDP link local: (not bound)
2023-05-11 10:26:21 UDP link remote: [AF_INET]x.x.x.x:443

y a t il d'autres choses à modifier?

Code : Tout sélectionner

dev tun
client
proto udp
ca "CA.cert.pem"
cert "openvpnclient.cert.pem"
key "openvpnclient.pkey.pem"
remote vpn.trucmuche.fr 443
persist-key
persist-tun
compress lz4
verb 3
mute 20
cipher AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
auth SHA256
reneg-sec 0
nobind
auth-user-pass
tls-cipher "DEFAULT:@SECLEVEL=0"

[benjarobin]

Je pense que c'est bon, mais pas plus penché sur le sujet.
As tu vérifié que cela fonctionnait avec une connexion Fixe (fibre) d'abord ? Avec un peu de chance l'UDP est bloqué quelque part...

[benjibasson]

Bonsoir benjarobin

J'ai le même soucis pour me connecter à l'openVPN en UDP avec ma freebox fibre ainsi que ma ligne youprice qui fonctionne fluide en TCP
meme en mettant mmsfix 1300 et MTU à 1500 ou 1300 l'UDP ne passe pas quelque soit free mobile free fixe et youprice

et en IPV6 comme ça ne fonctionne pas mieux non plus

[benjarobin]

Sois ton responsable informatique c'est trompé, et l'udp n'est pas activé, soit il l'est sur un autre port que 443, soit ce port est bloqué par ton entreprise (vpn non testé en udp...).

[benjibasson]

Bonjour
au vue des investigations, le port udp 1194 est bloqué par notre proxy Volvo-groupe.
Comme nous sommes déja en cours de fin de contrat avec ce prestataire ils ne voudront rien savoir si nous leur écrivons.
La sortie du proxy et l'indépendance informatique est prévu pour dans quelque mois.

existe t il d'autre ports udp qui sont pas soumis au blocages a la con comme le http 80 https 443 qui sont impossibles de bloquer?

[benjarobin]

Bonjour, très souvent tous les ports UDP sont bloqués... Mais ce n'est pas à nous de poser cette question...

[benjibasson]

Bonjour
En ajoutant l'option

Code : Tout sélectionner

/gfx-h264:AVC444

Je constate que l'affichage est plus fluide l'écran se rafraichit en même temps, et même s'il y a des séquences vidéos, ça n'ignore plus mes cliques pour avancer ou sortir de là.