Auteur Sujet: Accès wifi TGV - neutralité (Lu 26571 fois)

vivien · « **Réponse #12 le:** 14 janvier 2021 à 19:37:15 »

J'ai pris une capture Wireshark devant un TGV vide équipé de WiFi au terminus, avant qu'il ne parte pour les dépôts.

La carte Wi-Fi de mon PC a l'adresse mac 20:10:7a:01:6a:b7 et je captais bien le réseau (j'étais positionné devant une porte ouverte)

Je ne comprends pas pourquoi tous ces DHCP NAK, un accusé de réception négatif.

La capture wireshark (30 Ko) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202101_sncf_tgv_requetes_dhcp_1.pcapng.gz

Je me suis positionné à l'entrée d'un TGV qui allait partir (cette fois ci mauvaise condition radio, car a cause des portes pour l’embarquement, impossible de m’approcher) et je vois pleins de DHCP NAK aussi :

La capture wireshark (30 Ko) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202101_sncf_tgv_requetes_dhcp_2.pcapng.gz

Si vous avez une explication, je suis preneur.

mattmatt73 · « **Réponse #13 le:** 14 janvier 2021 à 20:10:07 »

j'y suis dans le tgv, si tu veux des tests...

tu étais bien logués pour avoir du net ?

sinon, tu as uniquement le portail sncf inoui

vivien · « **Réponse #14 le:** 14 janvier 2021 à 20:21:53 »

La première fois pas moyen de me logger, je me suis demandé si ce n'était pas car le TGV partait au garage quelques minutes plus tard.

La seconde capture, j'ai réussi à me logger et les NAK, c'est pas mes périphériques si tu regarde les adresse mac, il y a de tout (le TGV se remplissait)

Par contre j'étais en limite de couverture, a coté de la motrice, j'ai peut être pas tous les paquets. Le surf était impossible tellement le signal était faible.

hwti · « **Réponse #15 le:** 15 janvier 2021 à 02:54:45 »

Citation de: vivien le 14 janvier 2021 à 19:37:15

Je me suis positionné à l'entrée d'un TGV qui allait partir (cette fois ci mauvaise condition radio, car a cause des portes pour l’embarquement, impossible de m’approcher) et je vois pleins de DHCP NAK aussi
Si vous avez une explication, je suis preneur.

Les DHCP NAK contiennent le message "requested address not available".

On ne voit pas forcément tous les échanges :
- il y a des paquets perdus (ou hors de portée de ton PC)
- certaines réponses sont probablement en unicast (même si les NAK sont en Broadcast) : on ne voit pas les DHCP Offer entre les Discover et Request

Les clients :
- 20:2d:07:de:10:47 (Samsung Galaxy A3 2016, Android 7)
- 34:41:5d:b0:5e:73 (PC Windows, carte Intel)
- 5c:66:6c:f8:02:11 (OPPO Reno 2, Android 9)
- 54:26:96:cd:a4:c3 (Apple, "MBP Hugues"

)
- ee:fd:4b:8b:2d:2d (henri.xxxx@orange.fr

)
- 94:65:2d:41:45:60 (OnePlus 5T, Android 10)
...

Tous demandent plusieurs fois la même IP, je suppose donc qu'ils l'ont reçue dans les DHCP Offer.
Donc le serveur leur propose une IP, puis répond qu'elle n'est pas disponible $:-\$
Le client fait une nouvelle requête, le serveur propose toujours la même IP, et donc il refuse encore de l'attribuer

Bref, ça a l'air super buggé

vivien · « **Réponse #16 le:** 15 janvier 2021 à 08:44:07 »

Quand il n'y aura plus besoin d'IPv4 (IPv6 only), cela sera plus simple...

Bon c'est pas demain.

vivien · « **Réponse #17 le:** 12 août 2021 à 19:46:07 »

J'ai réalisé de nouveaux tests dans le TGV, et il y a vraiment du mieux.

Par contre, j'ai oublié de faire deux tests, si vous prenez le TGV, je veut bien un retour sur deux tests que je décrits ci-dessous. Cela se teste facilement avec un PC, qu'il soit sous Linux, Windows ou MacOS.

Mais sinon, avant de vous décrire les deux tests qu'il me manque, voici un petit retour, j'ai testé pleins de type de sites web :
- Site de test de débit
- Sites de transfert de fichiers
- Sites de VPN
- Sites de téléchargements légaux
- Sites de téléchargements / streaming illégaux
- Sites de Remote control
- Sites ou plutôt nom de domaine qui était de la passé utilisé pour diffuser des malware / phishing
- Site de mining en hijacking
- Sites de hacking (tous fermés, mais si la catégorie étaient bloqués, il seraient probablement toujours dans la site et donc accès bloqué)
- Sites dans la catégorie "Nudity"
- Sites dans la catégorie "Adult"
=> plus rien n'est bloqué, sur ce coté là c'est bien neutre.

Pour prendre Windows update, voici ce que l'on avait avant en 2019 :

Quand on cherche à affiner le contenu qui était retourné à Windows update, cela donne ceci :

Windows update fait toujours des requêtes http en 2021 et cela fonctionne dans le TGV :

vivien · « **Réponse #18 le:** 12 août 2021 à 19:54:07 »

Oui, il y a encore des ports TCP ou UDP ou si on ne met pas le bon protocole, cela ne passe pas :

iperf3 bloque sur certaines ports TCP, comme le 443, 444, 445 ou 446, mais c'est bon sur le port TCP 80 : (le serveur appliwave.iperf.fr écoute iperf3 sur l'ensemble des ports , du port 1 au port 9240, sauf sur le port 5201, en IPv4 comme en IPv6, en TCP comme en UDP)

Voici le contenu de l'échange iperf3 sur le port 443 : La connexion s'ouvre, mais après avoir envoyé son message qui n'est pas un début de requête https, on n'a plus de réponse.

Les échanges texte :

Mais à noter que le test pas facile de faire du http/2 directement sur le port 80 (sans passer par du http/1.1) fonctionne avec la SNCF, alors que il y a encore des réfractaires chez qui cela ne fonctionne pas :

Citation de: vivien le 05 mars 2021 à 16:02:09

Démo en IPv4 avec le même opérateur mobile :
curl --http2-prior-knowledge -4 -o /dev/null http://fr.archive.ubuntu.com/

Trace coté client :

Dans le TGV, ce test "curl --http2-prior-knowledge " fonctionne parfaitement :

vivien · « **Réponse #19 le:** 12 août 2021 à 20:22:48 »

Voici les deux tests où j'ai besoin de votre aide, si vous prenez le TGV Inoui dans les prochains jours :

Test N°1 : DNS :

J'ai réalisé des tests DNS, les réponses sont toujours bonnes, mais j'ai oublié de tester ce qu'il se passe si on a mis un contrôle parental qui utilise un DNS tiers.

On a déjà vu des opérateurs qui répondent aux requêtes DNS avec leur propre serveur DNS, quel que soit l'IP spécifiée, ce qui permet de faire des demandes à des IPv4 où il est impossible qu'un serveur réponde normalement...

Citation de: vivien le 17 janvier 2020 à 10:29:57

La capture Wireshark pour vérifier que je dialogue bien avec :
- 1.0.0.0
- 240.0.0.0
- 255.255.255.254

Le test que je souhaite faire est très simple :

On interroge la requête DNS d'un site de la catégorie "Adult" avec :
- Le DNS 1.1.1.1 qui est un DNS standard
- Le DNS 1.1.1.3 qui est un DNS qui bloque les DNS des logiciels malveillants et les sites pour adulte, cf https://1.1.1.1/family/

Voici le test à réaliser :

- Sous Windows : nslookup tukif.com 1.1.1.1 et nslookup tukif.com 1.1.1.3
- Sous Linux et OS X : dig tukif.com @1.1.1.1 et dig tukif.com @1.1.1.3. En cas de problème avec dig, il est également possible d'utiliser nslookup.

On va vérifier que dans le premier cas on a bien accès aux IPv4 du site et que dans le second cas on à 0.0.0.0 qui est retourné.

Si l'opérateur répond directement a toutes les requêtes DNS, on aura des IP autres que 0.0.0.0 pour le second test.

vivien · « **Réponse #20 le:** 12 août 2021 à 20:42:37 »

Test N°2 : Vitesse de chargement de sites SNCF quand on est en débit réduit

Le débit dans le TGV peut être assez élevé, comme le montre ce test de débit :

Quand vous avez dépassé votre fair use, vous passez en débit réduit, avec une limitation à 128 Kb/s symétrique, un débit utilisé par de nombreux opérateurs mobiles quand on dépasse le fair use.

Le fair use n'est pas indiqué : On est au début du voyage à 100% en seconde classe (et peut être à 200% en première classe, je ne sais pas si cela a évolué). Pour mon voyage de 1h j'ai estimé que le fair use est de 800 Mo par adresse mac. Je ne sais pas si cela varie en fonction de la durée du trajet. Chaque adresse mac a son propre compteur, vous pouvez déclarer plusieurs équipements sur un même billet, avec 3 équipements, vous aurez 800 Mo pour chacun des 3 périphériques, soit 2,4 Go au total.

Pour mon test, il faut être en débit réduit et donc consommer tout son forfait (à faire en fin de voyage)

Sur https://wifi.sncf vous devez avoir 0% de crédit internet restant :

Le débit est alors strictement réduit à 128 Kb/s sans possibilité de burst :

Les contenus qui sont en local dans le TGV, dont l'URL commence par https://wifi.sncf ne sont pas impacté par la limitation de débit qui ne concerne que Internet.

Exemple avec un podcast de RFI qui est bien en local dans le TGV :

Les différents services ci-dessous sont tous en local dans le TGV :

En allant sur les "Mes services à bord" qui sont sur sur la droite, on tombe sur un premier contenu qui est sur Internet, que j'ai entouré en bleu :

Cliquer sur "Le Bar : Consulter la carte" va ouvrir une image disponible sur Internet. Je souhaiterais savoir si cette image se charge à 128 Kb/s ou au débit maximum.

Dans "Mes services à l'arrivée", il y a deux services hébergés sur Internet, réserver un taxi et louer une voiture :

Là aussi, je suis intéressé pour savoir si en débit réduit cette page s'affiche rapidement ou lentement.

Dans "Tout savoir sur nous", il y a deux services hébergés sur Internet, "Agir pour la planète" et "Visiter sncf.com" :

Ne pas hésiter à visiter ces pages en débit normal puis en débit réduit.

Pour ne pas être impacté par le cache du navigateur, qui risque de mémoriser le contenu, je recommande de vider le cache du navigateur avant le second accès.

Vider le cache du navigateur

Appuyer simultanément sur les touches "Majuscules" + "Ctrl" + "Suppr" du clavier :

Une fenêtre apparaît :
1/ Cliquez sur Détails
2/ Décochez toutes les cases sauf Cache afin de ne supprimer que le cache
3/ En haut, pour l'intervalle à effacer, choisissez tout
4/ Cliquez sur Effacer maintenant

mattmatt73 · « **Réponse #21 le:** 12 août 2021 à 21:35:43 »

nslookup tukif.com 1.1.1.1
DNS request timed out.
timeout was 2 seconds.
Serveur : UnKnown
Address: 1.1.1.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur UnKnown est dépassé.

nslookup tukif.com 1.1.1.3
DNS request timed out.
timeout was 2 seconds.
Serveur : UnKnown
Address: 1.1.1.3

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur UnKnown est dépassé.

vivien · « **Réponse #22 le:** 12 août 2021 à 21:38:28 »

Oh !

La page https://1.1.1.1/ se charge bien ?

Que donne "nslookup tukif.com" sans préciser de serveurs ?

Dans mon TGV, le site web tukif.com était bien accessible (c'est un site de la saisine CSA de novembre 2020)

mattmatt73 · « **Réponse #23 le:** 12 août 2021 à 21:41:34 »

Citation de: vivien le 12 août 2021 à 21:38:28

Oh !

La page https://1.1.1.1/ se charge bien ?

Que donne "nslookup tukif.com" sans préciser de serveurs ?

Oui

et

nslookup tukif.com
Serveur : UnKnown
Address: 10.92.0.4

Réponse ne faisant pas autorité :
Nom : tukif.com
Addresses: 104.19.141.99
104.19.140.99