La Fibre
Télécom => Réseau => 
VPN => Discussion démarrée par: vivien le 17 août 2020 à 18:22:17
-
Limitation de débit de certains opérateurs sur le port TCP 1723 (PPTP) ?
J'ouvre ce sujet pour savoir si vous avez des débits plus faible sur le port TCP 1723.
Concrètement comment le vérifier ?
Simplement en téléchargeant un fichier de 1 Go sur le port 1723 (exemple: https://bouygues.testdebit.info:1723/1G.iso ) et un autre sur le même serveur sur un autre port (par exemple https://bouygues.testdebit.info/1G.iso pour le port 443)
D'autres serveurs sont possibles, comme celui de K-Net ( https://k-net.testdebit.info:1723/1G.iso ) Scaleway ( https://scaleway.testdebit.info:1723/1G.iso ) ou Ikoula ( https://ikoula.testdebit.info:1723/1G.iso ). Vous pouvez aussi prendre un fichier de 10 Go ( https://bouygues.testdebit.info:1723/10G.iso ) ou 100 Mo ( https://bouygues.testdebit.info:1723/100M.iso )
Il est aussi intéressant de comparer IPv4 et IPv6.
=> Tutoriel pour Windows (https://lafibre.info/tester-son-debit/curl-upload/), pour Linux (https://lafibre.info/tester-son-debit/curl-linux/) ou pour MacOS (https://lafibre.info/tester-son-debit/curl-mac/)
Voici un exemple concret avec une connexion Orange FTTH (Livebox v3 au cas où ce serait elle qui bride le débit) et le serveur Bouygues, sur un PC avec connexion Ethernet 100 Mb/s : On voit qu'on a le débit max sur le port 1722 (mais c'est le cas avec tous les ports sauf le 1723) et que le débit est moindre sur le port 1723. En IPv6, le port 1723 n'est pas limité en débit.
(https://lafibre.info/testdebit/ubuntu/202008_orange_ftth_limitation_debit_port1723_1.png)
Même connexion, mais avec le serveur K-Net : On voit qu'on a exactement les mêmes débits.
(https://lafibre.info/testdebit/ubuntu/202008_orange_ftth_limitation_debit_port1723_2.png)
Je tiens à préciser que je ne suis pas encore éligible à la fibre Orange et que je dois prendre la main sur un vieux PC chez mes parents :
(https://lafibre.info/testdebit/ubuntu/202008_orange_ftth_limitation_debit_port1723_3.png)
-
SFR sur me câble : aucun souci sur le port 1723. Par contre SFR en 4G, j'ai une baisse de débit sur le port 1723 avec le mode modem et en direct sur mon Android !
Test avec le mode modem sur mon Samsung Galaxy s8 : (les autres ports n'ont pas de limitation de débit)
(https://lafibre.info/testdebit/ubuntu/202008_sfr_4g_limitation_debit_port1723.png)
Edit (merci à hinoto) : Bouygues Telecom FTTH IPv4 :
(https://lafibre.info/testdebit/ubuntu/202008_bouygues_ftth_limitation_debit_port1723_ipv4.png)
Bouygues Telecom FTTH IPv6 :
(https://lafibre.info/testdebit/ubuntu/202008_bouygues_ftth_limitation_debit_port1723_ipv6.png)
-
Sur ma connexion Orange FTTH 1 Gbps descendant, sans Livebox (remplacée par un ER4). Le débit va effectivement du simple au double:
zoc@proxmox-2 ~ > wget -4 -O /dev/null https://bouygues.testdebit.info:1723/1G.iso
--2020-08-17 18:59:36-- https://bouygues.testdebit.info:1723/1G.iso
Resolving bouygues.testdebit.info (bouygues.testdebit.info)... 89.84.1.222
Connecting to bouygues.testdebit.info (bouygues.testdebit.info)|89.84.1.222|:1723... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-iso9660-image]
Saving to: ‘/dev/null’
/dev/null 100%[=============================================================>] 953.67M 43.4MB/s in 21s
2020-08-17 18:59:57 (45.5 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]
zoc@proxmox-2 ~ > wget -4 -O /dev/null https://bouygues.testdebit.info:1722/1G.iso
--2020-08-17 19:00:09-- https://bouygues.testdebit.info:1722/1G.iso
Resolving bouygues.testdebit.info (bouygues.testdebit.info)... 89.84.1.222
Connecting to bouygues.testdebit.info (bouygues.testdebit.info)|89.84.1.222|:1722... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-iso9660-image]
Saving to: ‘/dev/null’
/dev/null 100%[=============================================================>] 953.67M 83.5MB/s in 12s
2020-08-17 19:00:20 (82.9 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]
-
Bouygues FTTH Paris IPv4.
1 speed = 226.9 Mbps time = 7.936283278s size = 225116160 225.1 MB url https://bouygues.testdebit.info:1723/1G.iso
summary: speed = 226.9 Mbps time = 7.936283278s size = 225116160 225.1 MB1 flux: 226.9 Mbps
4 flux en meme temps:
1 speed = 39.1 Mbps time = 7.935541415s size = 38813696 38.8 MB url https://bouygues.testdebit.info:1723/1G.iso
2 speed = 56.1 Mbps time = 7.935231637s size = 55689216 55.7 MB url https://bouygues.testdebit.info:1723/1G.iso
3 speed = 84.0 Mbps time = 7.935615985s size = 83361792 83.4 MB url https://bouygues.testdebit.info:1723/1G.iso
4 speed = 49.6 Mbps time = 7.934567663s size = 49168384 49.2 MB url https://bouygues.testdebit.info:1723/1G.iso
summary: speed = 228.9 Mbps time = 7.935615985s size = 227033088 227.0 MB
4 flux: 228.9 Mbps
-> c'est pas par flux la limitation mais global.
derriere la meme bbox , 2 pc en même temps:
xxxx(local): summary: speed = 128.7 Mbps time = 7.9599205s size = 128008192 128.0 MB
xxxx(remote): summary: speed = 107.1 Mbps time = 7.941155324s size = 106332160 106.3 MB
limite totale a 228 Mbps aussi
avec le port par défaut:
1 speed = 230.4 Mbps time = 7.886600083s size = 227164160 227.2 MB url https://bouygues.testdebit.info/1G.iso
2 speed = 246.0 Mbps time = 7.887989912s size = 242597888 242.6 MB url https://bouygues.testdebit.info/1G.iso
3 speed = 228.8 Mbps time = 7.886795463s size = 225558528 225.6 MB url https://bouygues.testdebit.info/1G.iso
4 speed = 240.9 Mbps time = 7.887594814s size = 237469696 237.5 MB url https://.bouygues.testdebit.info/1G.iso
summary: speed = 946.0 Mbps time = 7.887989912s size = 932790272 932.8 MB
donc débit OK.
Orange - Livebox Pro FTTH (tests en IPv4):
idem, mono/multi session.
limité a 62 Mbps.
Online/Scaleway - Dedibox 1Gbps (IPv6):
resultats identiques entre port 443 et le port 1723, pas de limitation. idem IPv4 ou IPv6.
-
Par contre aucun problème (débits similaires) en IPv6:
zoc@proxmox-2 ~ > wget -6 -O /dev/null https://bouygues.testdebit.info:1723/1G.iso
--2020-08-17 19:05:59-- https://bouygues.testdebit.info:1723/1G.iso
Resolving bouygues.testdebit.info (bouygues.testdebit.info)... 2001:860:deff:1000::2
Connecting to bouygues.testdebit.info (bouygues.testdebit.info)|2001:860:deff:1000::2|:1723... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-iso9660-image]
Saving to: ‘/dev/null’
/dev/null 100%[=============================================================>] 953.67M 102MB/s in 9.4s
2020-08-17 19:06:08 (101 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]
zoc@proxmox-2 ~ > wget -6 -O /dev/null https://bouygues.testdebit.info:1722/1G.iso
--2020-08-17 19:06:16-- https://bouygues.testdebit.info:1722/1G.iso
Resolving bouygues.testdebit.info (bouygues.testdebit.info)... 2001:860:deff:1000::2
Connecting to bouygues.testdebit.info (bouygues.testdebit.info)|2001:860:deff:1000::2|:1722... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-iso9660-image]
Saving to: ‘/dev/null’
/dev/null 100%[=============================================================>] 953.67M 101MB/s in 9.4s
2020-08-17 19:06:26 (101 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]
-
zoc : tu pourrais faire un test en IPv4 pour comparer ?
kgersen : 228 Mb/s sur le port 1723, mais c'est bien 930 Mb/s sur les autres ports ? (tu ne le précise pas, c'est un peu implicite, mais pour remonter le problème, je veut bien un comparatif avec un autre port).
Quand IPv6 est disponible, c'est intéressant de tester en IPv6 pour voir si le pb est présent ou non.
-
zoc : tu pourrais faire un test en IPv4 pour comparer ?
il l'a fait 2 post au dessus ;)
-
Exact, j'avais zappé.
Donc tu n'as pas la même limite de débit que mes parents :
- Mes parents : 6,9 Mo/s avec une Livebox v3 avec un abonnement Sosh 300 Mb/s sur Melun (77)
- Zoc : 45 Mo/s avec un routeur ER4 qui remplace la livebox et un abonnement Orange 1 Gb/s sur Antibes (06).
Ce serait lié à la box ?
L'abonnement ?
Pour d'autres clients Orange, je suis intéressé pour savoir la version de la livebox pour voir si cela influence.
-
kgersen : 228 Mb/s sur le port 1723, mais c'est bien 930 Mb/s sur les autres ports ? (tu ne le précise pas, c'est un peu implicite, mais pour remonter le problème, je veut bien un comparatif avec un autre port).
oui c'est full speed sur le port par défaut (443).
on le voit bien si on fait 1723 et 443 en même temps:
1 speed = 225.9 Mbps time = 7.912406263s size = 223395840 223.4 MB url https://bouygues.testdebit.info:1723/1G.iso
2 speed = 716.8 Mbps time = 7.912697255s size = 708984832 709.0 MB url https://bouygues.testdebit.info/1G.iso
summary: speed = 942.7 Mbps time = 7.912697255s size = 932380672 932.4 MB
-
Possible de tester L2TP aussi ? J'ai un doute depuis quelques années...
-
Pour d'autres clients Orange, je suis intéressé pour savoir la version de la livebox pour voir si cela influence.
comme indiqué plus haut:
Orange - Livebox Pro FTTH (tests en IPv4):
idem, mono/multi session.
limité a 62 Mbps.
c'est une Livebox Pro 4 FTTH , Paris 2eme.
cela ne dépasse pas 64 Mbps (8 Mo/s) au mieux pour les flux sur le port 1723
-
Il semble que la différence de débit soit reproductible sur un FTTH Free en IPv4 uniquement.
J'ai des comportements assez bizarres cela dit, peut-être lié à une saturation sur le réseau interne de Free donc c'est compliqué d'être complètement sûr de ce qui se passe...
Le premier chiffre est en IPv4, le deuxième en IPv6.
http://scaleway.testdebit.info/1G.iso => 105 Mo/s | 106 Mo/s
https://scaleway.testdebit.info/1G.iso => 35,7 Mo/s | 38,6 Mo/s
https://scaleway.testdebit.info:1722/1G.iso => 34,4 Mo/s | 34,8 Mo/s
https://scaleway.testdebit.info:1723/1G.iso => 16,3 Mo/s | 37,0 Mo/s
http://bouygues.testdebit.info/1G.iso => 49,6 Mo/s | 58,9 Mo/s
https://bouygues.testdebit.info/1G.iso => 39,0 Mo/s | 38,6 Mo/s
https://bouygues.testdebit.info:1722/1G.iso => 38,6 Mo/s | 36,8 Mo/s
https://bouygues.testdebit.info:1723/1G.iso => 16,6 Mo/s | 32,5 Mo/s
Possible de tester L2TP aussi ? J'ai un doute depuis quelques années...
Port 1701 ? Si oui, je ne vois rien de spécial (même comportement que sur les ports 443 et 1722).
-
Livebox 5 (firmware 2.5.10): 3,5Mo/s en IPv4 !
Comme pour kgersen, la limite semble globale, avec plusieurs flux on ne va pas plus vite :
~ ᐅ curl -Z -4 -o /dev/null -o /dev/null https://bouygues.testdebit.info:1723/100M.iso https://bouygues.testdebit.info:1723/100M.iso
DL% UL% Dled Uled Xfers Live Qd Total Current Left Speed
100 -- 190M 0 2 0 0 0:00:54 0:00:54 --:--:-- 3611k
1Gbps (111Mo/s) en IPv6, ou sur le port 1722.
Linux a un module ip_conntrack_pptp, il y a une gestion spéciale pour identifier les connexions (firewall), et le NAT.
Mais là, même si le NAT n'est pas accéléré et ça reste traité par le CPU, le débit est très faible (le CPU de la LB5 est plus lent que celui de la LB4, mais il ne devrait pas être deux fois plus lent que la LB3).
- Mes parents : 1,18 Mo/s avec une Livebox v3 avec un abonnement Sosh 300 Mb/s sur Melun (77)
1,18Mo/s c'est ton résultat en 4G SFR, tes captures donnent un peu moins de 8Mo/s avec une Livebox 3.
-
serveurs scaleway ou bouygues meme résultats pour le port 1723 derriere une livebox ou une bbox.
le serveur scaleway.testdebit.info a du mal par contre en mono session a dépasser 300 Mbps quelque soit le port.
j'ai mis nspeed 0.3 a dispo pour tester sans matraquer les serveurs de test: http://nspeed.org/nspeed-client/v0.3a/ (penser a chmod +x sur Linux/Mac)
utiliser l'option "-timeout 4" pour limiter le test a 4 secondes (ou plus si 4s sont insuffisantes pour atteindre le débit max chez vous, par défaut c'est 8 secondes):
pour tester un flux:
./nspeed_linux_amd64 -timeout 4 https://bouygues.testdebit.info:1723/1G.iso
j'ai pas encore d'option ipv4/ipv6 mais Vivien a mis des dns qui vont bien:
./nspeed_linux_amd64 -timeout 4 https://ipv4.bouygues.testdebit.info:1723/1G.iso
ou
./nspeed_linux_amd64 -timeout 4 https://ipv6.bouygues.testdebit.info:1723/1G.iso
pour plusieurs flux, ajouter autant d'url que vous voulez (la limite est le nombre de connections tcp simultanées de l'OS ou la taille max de la ligne de commande):
4 flux identiques:
./nspeed_linux_amd64 -timeout 4 https://bouygues.testdebit.info/1G.iso https://bouygues.testdebit.info/1G.iso https://bouygues.testdebit.info/1G.iso https://bouygues.testdebit.info/1G.iso
2 flux depuis bouygues, 2 flux depuis scaleway
./nspeed_linux_amd64 -timeout 4 https://bouygues.testdebit.info/1G.iso https://bouygues.testdebit.info/1G.iso https://scaleway.testdebit.info/1G.iso https://scaleway.testdebit.info/1G.iso
2 flux 1723 bouygues et 2 flux 1723 scaleway en IPv4:
./nspeed_linux_amd64 -timeout 4 https://ipv4.scaleway.testdebit.info:1723/1G.iso https://ipv4.scaleway.testdebit.info:1723/1G.iso https://ipv4.bouygues.testdebit.info:1723/1G.iso https://ipv4.bouygues.testdebit.info:1723/1G.iso
livebox : ca plafonne a 62 Mbps
1 speed = 12.4 Mbps time = 3.923869384s size = 6094848 6.1 MB url https://ipv4.scaleway.testdebit.info:1723/1G.iso
2 speed = 14.8 Mbps time = 3.943508786s size = 7290880 7.3 MB url https://ipv4.scaleway.testdebit.info:1723/1G.iso
3 speed = 15.0 Mbps time = 3.947215366s size = 7421952 7.4 MB url https://ipv4.bouygues.testdebit.info:1723/1G.iso
4 speed = 19.1 Mbps time = 3.947892219s size = 9404416 9.4 MB url https://ipv4.bouygues.testdebit.info:1723/1G.iso
summary: speed = 61.2 Mbps time = 3.947892219s size = 30212096 30.2 MB
si on rajoute un 5eme flux pas sur le port 1723 il remplit le reste:
./nspeed_linux_amd64 -timeout 4 https://ipv4.scaleway.testdebit.info:1723/1G.iso https://ipv4.scaleway.testdebit.info:1723/1G.iso https://ipv4.bouygues.testdebit.info:1723/1G.iso https://ipv4.bouygues.testdebit.info:1723/1G.iso https://ipv4.bouygues.testdebit.info/1G.iso
donne
1 speed = 11.3 Mbps time = 3.895634494s size = 5505024 5.5 MB url https://ipv4.scaleway.testdebit.info:1723/1G.iso
2 speed = 13.4 Mbps time = 3.920725637s size = 6569984 6.6 MB url https://ipv4.scaleway.testdebit.info:1723/1G.iso
3 speed = 17.6 Mbps time = 3.921221372s size = 8650752 8.7 MB url https://ipv4.bouygues.testdebit.info:1723/1G.iso
4 speed = 16.1 Mbps time = 3.925833293s size = 7897088 7.9 MB url https://ipv4.bouygues.testdebit.info:1723/1G.iso
5 speed = 832.0 Mbps time = 3.928464702s size = 408584192 408.6 MB url https://ipv4.bouygues.testdebit.info/1G.iso
summary: speed = 890.3 Mbps time = 3.928464702s size = 437207040 437.2 MB
vous pouvez aussi mélanger ipv4 et ipv6 en meme temps.
A noter que derriere une bbox:
flux 1723 scaleway seul : 230 Mbps
flux 1723 bouygues seul: 230 Mbps
flux avec les 2 ensembles:
1 speed = 29.9 Mbps time = 3.935719482s size = 14712832 14.7 MB url https://ipv4.scaleway.testdebit.info:1723/1G.iso
2 speed = 195.8 Mbps time = 3.947736777s size = 96632832 96.6 MB url https://ipv4.bouygues.testdebit.info:1723/1G.iso
summary: speed = 225.6 Mbps time = 3.947736777s size = 111345664 111.3 MB
scaleway se fait 'bouffer' par bouygues (peut-être une histoire de bbr/cubic?)
-
Voila pour moi avec IDM sur 4 lien.
ipV4 port 443
(https://zupimages.net/up/20/34/exc0.jpg)
Ipv6 port 443
(https://zupimages.net/up/20/34/nfe7.jpg)
ipV4 port 1722
(https://zupimages.net/up/20/34/8a00.jpg)
ipv6 port 1722
(https://zupimages.net/up/20/34/f90o.jpg)
ipv4 port 1723 la ya un bleme
(https://zupimages.net/up/20/34/tl3k.jpg)
et pour finir ipv6 port 1723
(https://zupimages.net/up/20/34/u5z2.jpg)
Livebox 5
1.6 Version de firmware 2.5.10
1.7 Version de firmware Orange g0-f-fr
-
Bonjour,
ici, depuis orange ftth abonnement jet 2016 (sans livebox)
test effectué a 3h du mat
--2020-08-18 03:14:21-- https://bouygues.testdebit.info:1723/1G.iso
Résolution de bouygues.testdebit.info (bouygues.testdebit.info)… 89.84.1.222
Connexion à bouygues.testdebit.info (bouygues.testdebit.info)|89.84.1.222|:1723… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/x-iso9660-image]
Sauvegarde en : « /dev/null »
/dev/null 100%[=====================================================================================================>] 953,67M 100MB/s in 10s
2020-08-18 03:14:31 (92,5 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
--2020-08-18 03:14:49-- https://bouygues.testdebit.info:1723/1G.iso
Résolution de bouygues.testdebit.info (bouygues.testdebit.info)… 2001:860:deff:1000::2
Connexion à bouygues.testdebit.info (bouygues.testdebit.info)|2001:860:deff:1000::2|:1723… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/x-iso9660-image]
Sauvegarde en : « /dev/null »
/dev/null 100%[=====================================================================================================>] 953,67M 96,6MB/s in 11s
2020-08-18 03:15:00 (88,8 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
aucune limitation de débit constaté. je referai un test demain dans la journée afin de voir si bridage il y a :)
Jerem
-
Merci tous vos tests. Je récapitule ici vos tests :
Limitation :
- Sosh 300 Mb/s sur Melun (77) avec Livebox 3 : Limitation à 56 Mb/s en IPv4 (pas de limite en IPv6) - testé par Vivien
- Orange 1 Gb/s sur Paris (75) avec Livebox Pro FTTH : Limitation à 62 Mb/s en IPv4 - testé par kgersen
- Orange 1 Gb/s sur Chambly (60) avec Livebox 5 : Limitation à 29 Mb/s en IPv4 (pas de limite en IPv6) - testé par hwti
- Orange 1 Gb/s sur Château-Thierry (02) avec Livebox 5 : Limitation à 29 Mb/s en IPv4 (pas de limite en IPv6) - testé par Jiajo
- Orange 1 Gb/s sur Antibes (06) avec routeur ER4 : Limitaiton à 364 Mb/s en IPv4 (pas de limite en IPv6) - testé par zoc
- Bouygues 1 Gb/s sur Paris (75) avec Bbox Wi-Fi 6 : Limitation à 228 Mb/s en IPv4 - testé par kgersen
- Free FTTH 1 Gb/s sur Orsay (91) : limitation à 130 Mb/s en IPv4 (pas de limite en IPv6) - testé par underground78
- SFR 4G sur Paris (75) avec Samsung S8 pour mode modem : limitation à 9,5 Mb/s en IPv4 - testé par Vivien
Pas de limitation (ou limitation non visible car ce sont des abonnements à 100 Mb/s) :
- Orange 1 Gb/s sur Antibes (06) avec routeur Debian : Pas de limitation - testé par jeremyp3
- K-Net 100 Mb/s dans l'Ain (01) : pas de limitation sur ce port - testé par Nico_S
- RED 100 Mb/s sur Vitry-sur-Seine (94) avec Sagem F@st 3284DC : pas de limitation sur ce port - testé par Vivien (test ci-dessous) :
$ wget -4 -O /dev/null https://bouygues.testdebit.info:1723/100M.iso
--2020-08-18 09:32:50-- https://bouygues.testdebit.info:1723/100M.iso
Résolution de bouygues.testdebit.info (bouygues.testdebit.info)… 89.84.1.222
Connexion à bouygues.testdebit.info (bouygues.testdebit.info)|89.84.1.222|:1723… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 100000000 (95M) [application/x-iso9660-image]
Enregistre : «/dev/null»
/dev/null 100%[=========================================================================>] 95,37M 11,3MB/s ds 8,3s
2020-08-18 09:32:58 (11,5 MB/s) - «/dev/null» enregistré [100000000/100000000]
Un volontaire pour faire un test avec un PC directement connecté à l'ONT ?
Ma première hypothèse est que le port 1723 nécessite d'analyser le trafic et donc bloque les accélérateurs des box.
Je suis étonné par les contre-performance des Livebox 5.
J'ai des comportements assez bizarres cela dit, peut-être lié à une saturation sur le réseau interne de Free donc c'est compliqué d'être complètement sûr de ce qui se passe...
Le premier chiffre est en IPv4, le deuxième en IPv6.
http://scaleway.testdebit.info/1G.iso => 105 Mo/s | 106 Mo/s
https://scaleway.testdebit.info/1G.iso => 35,7 Mo/s | 38,6 Mo/s
Je suis intéressé pour des tests sur le port 1723 le matin.
J'hallucine un peu, Free priorise le port 80 sur le port 443 en cas de saturation ?
-
Ma première hypothèse est que le port 1723 nécessite d'analyser le trafic et donc bloque les accélérateurs des box.
C'est probablement ça.
On voit le problème sur un trafic TLS, mais ça n'implique pas qu'il soit présent sur du PPTP (peut-être que l'accélération est mise en place une fois le flux reconnu).
-
Alors je serais étonné que cela ne soit par sur un véritable trafic PPTP.
A voir si les débits sont les mêmes sur le port 21. Sur ce port il est nécessaire de modifier à la volée les IP qui sont encapsulée dans le contenu des paquets (FTP est un protocole vraiment mal fait, bon, il est excusé vu son age).
Pour tester le port 21 :
- Serveur Bouygues : wget -O /dev/null https://bouygues.testdebit.info:21/1G.iso
- Serveur K-Net : wget -O /dev/null https://k-net.testdebit.info:21/1G.iso
- Serveur Scaleway : wget -O /dev/null https://scaleway.testdebit.info:21/1G.iso
- Serveur Ikoula : wget -O /dev/null https://ikoula.testdebit.info:21/1G.iso
J'ai donné les commandes pour Linux, à adapter si vous utilisez Windows ou MacOS.
-
de mon coté a marseille, pas de difference entre 1723 ou pas, mais grosse difference entre http/https :
wget -4 -O NUL https://bouygues.testdebit.info:1723/1G.iso
NUL 100%[=================================================>] 953,67M 39,6MB/s in 24s
wget -4 -O NUL https://bouygues.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 24,5MB/s in 39s
wget -4 -O NUL http://bouygues.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 111MB/s in 8,7s
wget -6 -O NUL https://bouygues.testdebit.info:1723/1G.iso
NUL 100%[=================================================>] 953,67M 40,4MB/s in 24s
wget -6 -O NUL https://bouygues.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 40,0MB/s in 24s
wget -6 -O NUL http://bouygues.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 109MB/s in 8,9s
wget -6 -O NUL https://scaleway.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 36,3MB/s in 26s
wget -6 -O NUL https://scaleway.testdebit.info:1723/1G.iso
NUL 100%[=================================================>] 953,67M 36,3MB/s in 26s
wget -6 -O NUL http://scaleway.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 105MB/s in 9,1s
wget -4 -O NUL https://scaleway.testdebit.info:1723/1G.iso
NUL 100%[=================================================>] 953,67M 38,5MB/s in 25s
wget -4 -O NUL https://scaleway.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 33,3MB/s in 26s
wget -4 -O NUL http://scaleway.testdebit.info/1G.iso
NUL 100%[=================================================>] 953,67M 111MB/s in 8,7s
-
Donc je ne suis pas le seul à avoir un comportement bizarre...
-
J'ai peur qu'il y ait vraiment un nouveau sujet neutralité chez Free.
Free_me: Ce sont des tests réalisés le matin ? (pour savoir si il y a une saturation possible du réseau)
Quelle est la box utilisée ? Pour le port 1723 on pense que la limitation cela pourrait être en fonction des chips qui équipe les box pour faire le NAT.
-
Quelle est la box utilisée ? Pour le port 1723 on pense que la limitation cela pourrait être en fonction des chips qui équipe les box pour faire le NAT.
Pour mes tests c'est une Freebox Révolution (r1) donc une veille box.
-
J'ai peur qu'il y ait vraiment un nouveau sujet neutralité chez Free.
Free_me: Ce sont des tests réalisés le matin ? (pour savoir si il y a une saturation possible du réseau)
Quelle est la box utilisée ? Pour le port 1723 on pense que la limitation cela pourrait être en fonction des chips qui équipe les box pour faire le NAT.
c'est la pop, oui test fait sur la derniere demi-heure
Par contre comme ca m'etonnais j'ai refais des tests dans une vm, je monte plus haut avec le wget de debian
j'ai refais 4 test sous windows et 4 test debian (vm), -6 -4 et 1723 ou non, tous sur le serveur bouygues. les 4 premiers tests sont sur windows, les 4 suivants dans la vm.
donc le wget de windows ne sature pas le cpu alors que debian oui
les 4 tests sur windows donnent 40Mo/s, ceux dans la vm entre 75 et 85Mo/s
-
Le routage sur les Freebox révolution / Mini 4k ont deux CPU contrairement aux autres box : un CPU de box Broaadcom standard et un CPU ARM de NAS bien plus puissant. Elles ont aussi deux RAM deux flash et deux OS.
Le SoC Broadcom BCM6368 à 400 MHz ne s'occuperait que de la partie xDSL.
Le SoC ARM Marvell Kirkwood 88F6281 à 1,2 GHz, bien plus puissant que ce que l'on trouve dans de nombreuses box, s'occuperait du NAT et d'encapsuler les paquets IPv4 dans des paquets IPv6.
Donc il n'est pas non plus étonnant de voir des débits sur le port 1723, si on part sur une limitation CPU (c'est seulement une hypothèse).
Pour la problématique http / https chez Free, j'ai ouvert un sujet distinct pour ne pas polluer le problème sur le port 1723 qui est bien différent.
=> Free FTTH : Limitation des débits en https (comparé à du trafic http) ? (https://lafibre.info/1gb-free/free-limitation-debit-https/)
-
LB4 Sosh 125Mb/s sur le port 1723 et 315Mb/s pour le 443
-
A voir si les débits sont les mêmes sur le port 21. Sur ce port il est nécessaire de modifier à la volée les IP qui sont encapsulée dans le contenu des paquets (FTP est un protocole vraiment mal fait, bon, il est excusé vu son age).
3,3Mo/s en IPv4
1,6Mo/s en IPv6 :o
Le CPU doit pouvoir examiner la connexion de contrôle FTP pour permettre le mode actif (commande PORT) : remplacer l'IP LAN envoyée par l'IP publique (en IPv4). et autoriser la connexion entrante (IPv4 et IPv6, à partir du moment où le firewall est activé).
Les données sont transférées sur une autre connexion, qui utilise un port dynamique et ne devrait pas avoir de limitation.
-
wget est notoirement mauvais sur Windows , meme sur certains Linux.
un curl récent est préférable.
-
effectivement avec curl, aucun soucis, et cpu tranquilou dans les 25% :
curl -4 https://bouygues.testdebit.info/1G.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 110M 0 0:00:08 0:00:08 --:--:-- 112M
curl -6 https://bouygues.testdebit.info/1G.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 107M 0 0:00:08 0:00:08 --:--:-- 109M
curl -6 https://bouygues.testdebit.info:1723/1G.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 107M 0 0:00:08 0:00:08 --:--:-- 109M
curl -4 https://bouygues.testdebit.info:1723/1G.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 108M 0 0:00:08 0:00:08 --:--:-- 110M
-
Merci tous vos tests. Je récapitule ici vos tests, avec les nouveaux tests et des précisions sur les box utilisées :
Limitation :
- Sosh 300 Mb/s sur Melun (77) avec Livebox 3 : Limitation à 56 Mb/s en IPv4 (pas de limite en IPv6) - testé par Vivien
- Orange 1 Gb/s sur Paris (75) avec Livebox Pro FTTH : Limitation à 62 Mb/s en IPv4 - testé par kgersen
- Sosh 300 Mb/s avec Livebox 4 : Limitation à 125 Mb/s en IPv4 - testé par Lucien
- Orange 1 Gb/s sur Chambly (60) avec Livebox 5 : Limitation à 29 Mb/s en IPv4 (pas de limite en IPv6) - testé par hwti
- Orange 1 Gb/s sur Château-Thierry (02) avec Livebox 5 : Limitation à 29 Mb/s en IPv4 (pas de limite en IPv6) - testé par Jiajo
- Orange 1 Gb/s sur Antibes (06) avec routeur Ubiquiti EdgeMax ER4 : Limitation à 364 Mb/s en IPv4 (pas de limite en IPv6) - testé par zoc
- Bouygues 1 Gb/s sur Paris (75) avec Bbox Wi-Fi 6 : Limitation à 228 Mb/s en IPv4 - testé par kgersen
- Free 1 Gb/s sur Orsay (91) en 10G-EPON avec Freebox révolution R1 : limitation à 130 Mb/s en IPv4 (pas de limite en IPv6) - testé par underground78
- Free 1 Gb/s sur Mondeville (14) en 10G-EPON avec Freebox Mini4k : limitation à 253 Mb/s en IPv4 (pas de limite en IPv6) - testé par Zweit
- SFR 4G sur Paris (75) avec Samsung S8 pour mode modem : limitation à 9,5 Mb/s en IPv4 - testé par Vivien
Pas de limitation (ou limitation non visible car ce sont des abonnements à 100 Mb/s) :
- Orange 1 Gb/s sur Antibes (06) avec routeur Debian (HP gen8 avec Intel Xeon E3-1220 V2 @3.1GHz) : Pas de limitation - testé par jeremyp3
- Free 2,5 Gb/s sur Marseille (13) avec Freebox Pop en P2P : pas de limitation à 1 Gb/s - testé par Free_me
- K-Net 100 Mb/s dans l'Ain (01) : pas de limitation sur ce port - testé par Nico_S
- RED 100 Mb/s sur Vitry-sur-Seine (94) avec Sagem F@st 3284DC : pas de limitation sur ce port - testé par Vivien
Tests de Zweit, avec Free 1 Gb/s sur Mondeville (14) en 10G-EPON avec Freebox Mini4k :
J'ai pu tester via un autre PC présent sur leur réseau. Il n'est pas tout jeune mais tient encore la route :)
i5-2500 @ 3.30 GHz, 12G RAM, Win 10 Pro 64 bits 1903
C:\Windows\System32>curl -4 http://bouygues.testdebit.info/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.8M
C:\Windows\System32>curl -4 http://bouygues.testdebit.info:81/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 100M
C:\Windows\System32>curl -4 https://bouygues.testdebit.info:82/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 0:00:01 --:--:-- 93.8M
C:\Windows\System32>curl -4 https://bouygues.testdebit.info/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.9M
C:\Windows\System32>curl -4 https://bouygues.testdebit.info:1723/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 31.7M 0 0:00:03 0:00:03 --:--:-- 31.7M
C:\Windows\System32>curl -4 https://bouygues.testdebit.info:8080/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.8M
C:\Windows\System32>curl -6 http://bouygues.testdebit.info/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 98.5M
C:\Windows\System32>curl -6 http://bouygues.testdebit.info:81/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 98.4M
C:\Windows\System32>curl -6 https://bouygues.testdebit.info:82/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.8M
C:\Windows\System32>curl -6 https://bouygues.testdebit.info/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.8M
C:\Windows\System32>curl -6 https://bouygues.testdebit.info:1723/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.9M
C:\Windows\System32>curl -6 https://bouygues.testdebit.info:8080/100M.iso --output NUL
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 95.3M 0 0:00:01 --:--:-- 0:00:01 96.9M
Soit en résumé :
IPv4 :
HTTP / 80 : 95.3 Mio/s
HTTP / 81 : 95.3 Mio/s
HTTPS / 82 : 95.3 Mio/s
HTTPS / 443 : 95.3 Mio/s
HTTPS / 1723 : 31.7 Mio/s
HTTPS / 8080 : 95.3 Mio/s
IPv6 :
HTTP / 80 : 95.3 Mio/s
HTTP / 81 : 95.3 Mio/s
HTTPS / 82 : 95.3 Mio/s
HTTPS / 443 : 95.3 Mio/s
HTTPS / 1723 : 95.3 Mio/s
HTTPS / 8080 : 95.3 Mio/s
-
wget est notoirement mauvais sur Windows , meme sur certains Linux.
un curl récent est préférable.
Perso j'avais testé aussi avec Curl sans voir de différence notable.
-
Petit point sur les tests Free :
Les deux qui sont limités sont sur une infrastructure IPv6 native (IPv4 encapsulé dans de l'IPv6) :
- Free 1 Gb/s sur Orsay (91) en 10G-EPON avec Freebox révolution R1 : limitation à 130 Mb/s en IPv4 (pas de limite en IPv6) - testé par underground78
- Free 1 Gb/s sur Mondeville (14) en 10G-EPON avec Freebox Mini4k : limitation à 253 Mb/s en IPv4 (pas de limite en IPv6) - testé par Zweit
Le test non limité est sur une infrastructure IPv4 native (IPv6 encapsulé dans de l'IPv4) :
- Free 2,5 Gb/s sur Marseille (13) avec Freebox Pop en P2P : pas de limitation à 1 Gb/s - testé par Free_me
Free_me va passer dans les prochains jours en architecture 10G-EPON, il pourra donc comparer pour voir si le passage d'un réseau IPv4 a un réseau IPv6 change quelques chose.
Pour rappel, chez les autres opérateurs c'est du dual-stack qui est déployé : L'IPv4 cohabite à coté de l'IPv6 sur le réseau d’accès.
Free lui n'a qu'un seul protocole sur l’accès IPv4 only ou IPv6 only.
-
Je suis curieux de savoir comment vous avez accès à vos ports: quelqu'un pour m'expliquer ? Merci d'avance.
-
Le port se spécifie en indiquant le numéro de port après le nom de domaine. Si tu ne spécifie pas de numéro, c'est le port 443 qui est utilisé pour https, 80 pour http,... chaque protocole a son numéro de port. Tu as peut-être déjà vu le port 110 pour POP3, 25 pour SMTP,...
Le port 1723, c'est pour monter des VPN PPTP, d'où sa présence dans la section VPN.
Exemple :
Port 1721 : https://bouygues.testdebit.info:1721/1G.iso
Port 1722 : https://bouygues.testdebit.info:1722/1G.iso
Port 1723 : https://bouygues.testdebit.info:1723/1G.iso
Port 1724 : https://bouygues.testdebit.info:1724/1G.iso
Bien sur il faut que le serveur écoute sur les ports demandé, mais c'est la cas du serveur proposé.
Sur ce forum l'URL commence par https://lafibre.info/vpn/ c'est donc le port 443 qui est utilisé comme 99,9999% des sites https.
-
Un volontaire pour faire un test avec un PC directement connecté à l'ONT ?
Ma première hypothèse est que le port 1723 nécessite d'analyser le trafic et donc bloque les accélérateurs des box.
Bien vu.
C'est nickel avec PC directement sur l'ONT!
https://lafibre.info/1gb-free/free-limitation-debit-https/msg784781/#msg784781
curl -4 -k -o NUL https://k-net.testdebit.info/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 119M 0 0:00:08 0:00:08 --:--:-- 113M
curl -4 -k -o NUL https://k-net.testdebit.info:1723/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 119M 0 0:00:08 0:00:08 --:--:-- 113M
-
Mais pour toi ce n'était pas déjà ok sur la box K-Net ?
Je veut bien le test sur la box pour montrer que le débit est réduit sur le port 1723
(désolé, mais c'est une preuve importante pour prouver que le pb n'est pas coté opérateur, mais coté box)
-
Le port 1723, c'est pour monter des VPN PPTP, d'où sa présence dans la section VPN.
J'ai le sentiment que ça se fourvoie depuis le début dans ce thread.
Le PPTP se compose:
1) d'un canal de contrôle sur une session TCP port 1723
2) d'un canal de donnée dans des paquets GRE à header modifié
Par ailleurs le PPTP c'est toujours un pot de pus à NATer: une session TCP d'un coté, des paquets GRE difficiles à associer à une session de l'autre s'il y a plusieurs IPs privées derrière le NAT, etc. Donc, le TCP port 1723 peut devoir passer via un ALG plutôt qu'en direct, sur du CGNAT. Ça pourrait expliquer des choses (pas un problème de neutralité mais de techno). Chercher à nf_conntrack_pptp pour quelques éléments sur des choses purement software (ce qui n'est pas le cas des devices à CGNAT).
Edit: devices à CGNAT, ou tout bêtement une box avec NAT offloadé/accéléré sur le SoC.
-
Mais pour toi ce n'était pas déjà ok sur la box K-Net ?
Je veut bien le test sur la box pour montrer que le débit est réduit sur le port 1723
(désolé, mais c'est une preuve importante pour prouver que le pb n'est pas coté opérateur, mais coté box)
Non, en 1G, la box bride en gros d'1/3 le port 1723.
https://lafibre.info/1gb-free/free-limitation-debit-https/msg784689/#msg784689
-
Merci Steph, j'avais surtout été attiré par le débit de ton port 80 (sans aucun).
Merci Symbol pour les détails qui expliquent bien les choses (et pour info le débit n'est pas limité sur le port TCP 1723 sur les tests que j'ai en vacance sur le réseau WiFirst - Wifirst dans les hotels Novotel / Accor: excellent (https://lafibre.info/wifirst/wifirst-novotel/))
-
Merci Steph, j'avais surtout été attiré par le débit de ton port 80 (sans aucun).
De rien.
Vincent O à répondu sur CAPS : Le PPTP ALG est activé sur les KBox, donc le traffic passe par le CPU.
https://forum.caps.services/index.php/topic,7996.msg101857.html#msg101857
https://en.wikipedia.org/wiki/Application-level_gateway
-
Possible de tester L2TP aussi ? J'ai un doute depuis quelques années...
Je me demande si la L2TP ALG ne risque pas d’obliger le trafic a passer par le CPU sur le port 1701, comme c'est le cas pour PPTP ALG sur le port 1723.
J'ai testé sur une box où le débit était limité sur le 1723 et ce n'est pas limité sur le 1701, mais c'est peut être différent sur d'autres box.
-
Le port 1701 est à 8Mo/s, mais je ne sais pas si c'est la K-box ou les protections de mon PC pro...
(Et Vincent m'a désactivé provisoirement PPTP ALG et du coup, je vais plus vite sur 1723 que sur 443
https://forum.caps.services/index.php/topic,7996.msg101860.html#msg101860)
-
Je me demande si la L2TP ALG ne risque pas d’obliger le trafic a passer par le CPU sur le port 1701, comme c'est le cas pour PPTP ALG sur le port 1723.
Pas besoin d'ALG pour ne nater qu'une simple session TCP: ici en PPTP, l'ALG est nécessaire pour associer intelligemment les paquets GRE à la session, afin de permettre à chaque client naté de monter un tunnel PPTP.
Le L2TPv2 (dans lequel passe du PPP) c'est de l'UDP ; le port source du LAC est généralement 1701 en pratique mais il peut être quelconque (donc il peut être PATé). Si en théorie le port source choisi par le LNS peut ne pas être 1701, la RFC raconte cependant que:
«It has been suggested that having the recipient choose an arbitrary source port (as opposed to using the destination port in the packet initiating the tunnel, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementors should consider the potential implication of this before before choosing an arbitrary source port.»
donc des ALG L2TP, ce n'est pas indispensable...
Le L2TPv3 (qui est très rare, et qui fait passer du L2 brut) peut passer sur de l'UDP (pareil que L2TPv2) ou directement sur protocole IP (protocol 115 - et là c'est un problème pour le NAT). Mais pour UDP sa RFC ajoute du reste que:
A NAT device that can pass TFTP traffic with variant UDP ports should be able to pass L2TP UDP traffic since both protocols employ similar policies with regard to UDP port selection.
Bref, pas besoin d'ALG L2TP en pratique.
-
Bref, pas besoin d'ALG L2TP en pratique.
moi j'aurai plutot dis : Bref, c'est un beau merdier.... ;)
-
Sur les box/routeur Linux , Netfilter a des modules spéciaux optionnels pour gérer les protocoles qui passent mal le NAT comme FTP, PPTP, GRE, etc.
pour ftp par exemple il y a:
nf_conntrack_ftp
nf_nat_ftp
Le 1er sert pour le suivi des connections et l'autre pour le NAT.
Ces modules s’appellent des "helpers". Si un module n'est pas installé ou activé dans l'OS ,le protocole en question ne subit de traitement particulier donc ne sera pas ralenti.
Les helpers les plus utilisés:
FTP (TCP 21)
H323 (UDP 1719, TCP 1720)
IRC (TCP 6667)
Netbios-NS (UDP 137)
PPTP (TCP 1723)
SIP (UDP 5060)
SNMP (UDP 161)
TFTP (UDP 69)
voila les ports limités derrière une BBox Wifi 6:
INFO[0004] #1 speed = 224.6 Mbps time = 3921 ms (3.92178237 s) size = 110.1 MB (105.0 MiB) url = https://ipv4.bouygues.testdebit.info:21/1G.iso
INFO[0004] #1 speed = 223.7 Mbps time = 3900 ms (3.9008171640000002 s) size = 109.1 MB (104.0 MiB) url = https://ipv4.bouygues.testdebit.info:1720/1G.iso
INFO[0004] #1 speed = 225.9 Mbps time = 3862 ms (3.862240007 s) size = 109.1 MB (104.0 MiB) url = https://ipv4.bouygues.testdebit.info:6667/1G.iso
INFO[0004] #1 speed = 226.3 Mbps time = 3929 ms (3.929008529 s) size = 111.1 MB (106.0 MiB) url = https://ipv4.bouygues.testdebit.info:1723/1G.iso
INFO[0004] #1 speed = 196.1 Mbps time = 3867 ms (3.8674794500000003 s) size = 94.8 MB (90.4 MiB) url = https://ipv4.bouygues.testdebit.info:5060/1G.iso
il y a donc: 21 (FTP), 1720 (H323), 1723 (PPTP), 6667(IRC), 5060(SIP)
la commande pour tester auto:
for p in 21 1719 1720 6667 137 1723 5060 161 69; do ./nspeed_linux_amd64 -timeout 4 https://ipv4.bouygues.testdebit.info:$p/1G.iso ; done
-
Derriere une Livebox 4 Pro:
INFO[0004] #1 speed = 63.6 Mbps time = 3908 ms (3.908326233 s) size = 31.0 MB (29.6 MiB) url = https://ipv4.bouygues.testdebit.info:21/1G.iso
INFO[0004] #1 speed = 62.4 Mbps time = 3956 ms (3.956543051 s) size = 30.9 MB (29.5 MiB) url = https://ipv4.bouygues.testdebit.info:1720/1G.iso
INFO[0004] #1 speed = 63.3 Mbps time = 3919 ms (3.919173499 s) size = 31.0 MB (29.6 MiB) url = https://ipv4.bouygues.testdebit.info:6667/1G.iso
INFO[0004] #1 speed = 63.9 Mbps time = 3947 ms (3.947535557 s) size = 31.5 MB (30.1 MiB) url = https://ipv4.bouygues.testdebit.info:1723/1G.iso
il y a donc : 21 (FTP), 1720 (H323), 1723 (PPTP), 6667(IRC)
Il y a en peut-être d'autres, je n'ai pas tester tous les ports possibles.
-
Le L2TPv2 (dans lequel passe du PPP) c'est de l'UDP ; le port source du LAC est généralement 1701 en pratique
Speedguide note du TCP 1701 : https://www.speedguide.net/port.php?port=1701
C'est une erreur ?
SIP (UDP 5060)
Il y a SIPS aussi.
Exemple avec une box câble SFR :
Référence sur le port 443 :
./nspeed_linux_amd64 -timeout 10 https://bouygues.testdebit.info/1G.iso
1 speed = 96.1 Mbps time = 9.928339644s size = 119291904 119.3 MB url https://bouygues.testdebit.info/1G.iso
summary: speed = 96.1 Mbps time = 9.928339644s size = 119291904 119.3 MB
Port SIP 5060 :
./nspeed_linux_amd64 -timeout 10 https://bouygues.testdebit.info:5060/1G.iso
1 speed = 122.8 kbps time = 8.538668044s size = 131072 131.1 kB url https://bouygues.testdebit.info:5060/1G.iso
summary: speed = 122.8 kbps time = 8.538668044s size = 131072 131.1 kB
Port SIP 5061 :
./nspeed_linux_amd64 -timeout 10 https://bouygues.testdebit.info:5061/1G.iso
1 speed = 122.8 kbps time = 8.53877267s size = 131072 131.1 kB url https://bouygues.testdebit.info:5061/1G.iso
summary: speed = 122.8 kbps time = 8.53877267s size = 131072 131.1 kB
Deux connexions simultanées sur le port 5060 :
./nspeed_linux_amd64 -timeout 10 https://bouygues.testdebit.info:5060/1G.iso https://bouygues.testdebit.info:5060/1G.iso
1 speed = 47.4 kbps time = 8.288688043s size = 49152 49.2 kB url https://bouygues.testdebit.info:5060/1G.iso
2 speed = 66.0 kbps time = 7.942146965s size = 65536 65.5 kB url https://bouygues.testdebit.info:5060/1G.iso
summary: speed = 110.7 kbps time = 8.288688043s size = 114688 114.7 kB
Port 5060 et 5061 simultanément :
./nspeed_linux_amd64 -timeout 10 https://bouygues.testdebit.info:5060/1G.iso https://bouygues.testdebit.info:5061/1G.iso
1 speed = 57.3 kbps time = 6.864785511s size = 49152 49.2 kB url https://bouygues.testdebit.info:5060/1G.iso
2 speed = 33.0 kbps time = 7.940527067s size = 32768 32.8 kB url https://bouygues.testdebit.info:5061/1G.iso
summary: speed = 82.5 kbps time = 7.940527067s size = 81920 81.9 kB
2 connexions 5060 et deux connexions 5061 :
1 speed = 37.8 kbps time = 6.94288849s size = 32768 32.8 kB url https://bouygues.testdebit.info:5060/1G.iso
2 speed = 21.1 kbps time = 6.218949448s size = 16384 16.4 kB url https://bouygues.testdebit.info:5060/1G.iso
3 speed = 31.5 kbps time = 4.159375999s size = 16384 16.4 kB url https://bouygues.testdebit.info:5061/1G.iso
4 speed = (too fast) time = 0s size = 0 0 B url https://bouygues.testdebit.info:5061/1G.iso
summary: speed = 75.5 kbps time = 6.94288849s size = 65536 65.5 kB
nSpeed est très pratique pour ces tests....
-
Le L2TPv2 (dans lequel passe du PPP) c'est de l'UDP ; le port source du LAC est généralement 1701 en pratique mais il peut être quelconque (donc il peut être PATé).
Speedguide note du TCP 1701 : https://www.speedguide.net/port.php?port=1701
C'est une erreur ?
C'est une erreur, L2TP n'est pas transporté sur TCP.