La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Débit fibre => Discussion démarrée par: fp001 le 19 décembre 2025 à 18:36:02
-
Bonjour à tous,
Je suis ce forum depuis quelques temps et je note la qualité des interventions et des intervenants.
Par ce message, je lance une bouteille à la mer aux experts Orange qui pourront peut être venir en aide sur un sujet qui commence à faire du bruit notamment chez les gamers.
En effet, il est constaté depuis plusieurs semaines maintenant une difficulté voir une impossibilité de jouer correctement aux jeux vidéos en soirée dont la communication avec le serveur de jeu passerait par une liaison "saturée" ou pire, volontairement bridée. Le jeu le plus impacté aujourd'hui est Star Citizen où il est tout bonnement impossible de se connecter au jeu entre 19h00 et 23h00. Sur le coup, beaucoup ont conclu que le jeu était en cause à cause de sa stabilité "aléatoire". Il est apparu qu'en passant par un VPN ou en faisant du split tunneling via VPN sur l'IP de connexion au serveur d'authentification, le problème disparaissait immédiatement :o. La diffusion de cette solution de contournement s'est vite diffusée et beaucoup de joueurs se sont rendus compte que Star Citizen n'était pas le seul jeu impacté.
Lors de ce problème, j'ai capturé des trames via Wireshark et j'ai pu constaté un tas de trames en erreur ou rejetées. Cela n'arrive pas en dehors de la période 19h00-23h00, ni en passant par un VPN.
Tout cela me rappelle la sombre époque du peering bridée chez Free...
Un post a été ouvert sur le forum Orange et il s'emblerait que leurs équipes ont pris en charge le sujet (mais sans date ni assurance de résolution)
https://communaute.orange.fr/t5/ma-connexion/Connexion-impossible-%C3%A0-STAR-CITIZEN/td-p/3365712
Voici l'IP de destination : 34.86.120.86 ( pub-sc-alpha-450-10966564.test1.cloudimperiumgames.com )
J'ai à disposition les trames si nécessaire.
Merci d'avance.
EDIT : Une mise à jour a été postée sur le forum Orange
Côté investigations, les analyses avancent : à ce stade, le défaut n’est pas identifié sur le réseau Orange mais sur un réseau international. Les tracert que vous nous avez transmis ont bien été partagés avec les différents acteurs concernés afin d’aider à l’identification de l’origine du problème.
Nos équipes restent pleinement mobilisées et les investigations se poursuivent avec les différents acteurs concernés. Nous reviendrons vers vous ici dès que nous disposerons de nouveaux éléments.
-
Moi, je me suis fait bannir du forum Orange - pourtant je suis abonné - Après avoir posté une (seule) question technique toute simple - où va ce monde...
> Vous pouvez leur transmettre ma page il y a "Connection on ASN 3215 Orange S.A. in Valdeblore (FR), France (UTC+1) at home, right at the very top of the mountain, the last one in the line. " en ROUGE (avec d'énorme pertes de paquets).
Bonjour,
Je me suis fait une page avec RRD (Robin Round Database) sur un Ping Latency entre les IPv4 des mes serveurs.
Elle est disponible dans le répertoire ./infos/ des serveurs.
Exemple, voici la vue (page web) depuis ma gateway en France : https://GATE.🇫🇷.◕‿◕.ST/infos/rrd-latency.html (https://GATE.🇫🇷.◕‿◕.ST/infos/rrd-latency.html)
(https://gate.xn--j77hya.xn--hwgz2tba.st/infos/rrd/latency_ipv4_graph-gate-fr_srv-ca.png)
Je ping depuis mes serveurs - vers -> le serveur Canadien : ping -q -n -c 3 158.69.126.137 toutes les minutes.
Le tutoriel est celui-ci : https://calomel.org/rrdtool.html
Explication du graphique : Ce graphique illustre le temps d'aller-retour (RTT) et la perte de paquets (PL). Le RTT est représenté en bleu. La perte de paquets est indiquée par la couleur de fond du graphique, variant selon la période où elle a été constatée. En l'absence de perte de paquets, le fond est blanc, comme dans l'exemple. En cas de perte de paquets, la couleur de fond varie du jaune au rouge en fonction de l'importance de la perte. Le graphique représente 24 heures de données avec une granularité d'une minute ; les heures sont indiquées sur l'axe des abscisses (x) en bas. L'axe des ordonnées (y) est automatiquement gradué en fonction des données collectées et indique la latence en millisecondes (ms) ; sa légende est imprimée à gauche et à droite. Le titre apparaît en noir en haut, et la date et l'heure de création du graphique sont affichées en filigrane gris clair en bas. Lors de la lecture du graphique, il est important de noter que les données les plus récentes se trouvent à droite et les plus anciennes à gauche.
En plus des graphs MRTG : https://GATE.🇫🇷.◕‿◕.ST/infos/mrtg.html (https://GATE.🇫🇷.◕‿◕.ST/infos/mrtg.html)
Salutations,
O.Romain.Jaillet-ramey (LAB3W.ORJ)
---
Si vous êtes sur la ligne ; mettez ce script en place pour savoir où sont les pertes de paquets - Entre Nice et chez moi s'il vous plaît ; vu que je suis le dernier sur la ligne à Valdeblore Saint-dalmas, France ;-)
---
PS : Je n'arrive toujours pas/plus à (re-)rentrer en IPv6 GUA sur mes serveurs at Home. J'ai eu une coupure d’électricité (orage) ; toutes les machines ont rebootées et puis tout refonctionne normalement.
C'est vraiment la m....
-
Moi, je me suis fait bannir du forum Orange - pourtant je suis abonné - Après avoir posté une (seule) question technique toute simple - où va se monde...
> Vous pouvez leur transmettre ma page il y a "Connection on ASN 3215 Orange S.A. in Valdeblore (FR), France (UTC+1) at home, right at the very top of the mountain, the last one in the line. " en ROUGE (avec d'énorme pertes de paquets).
C'est vraiment la m....
A la question où va ce monde ? je répondrais à la Pierre Dac ... Ton avenir est devant toi et tu l'auras derrière à chaque fois que tu feras demi tour !! 8)
-
OK, @Ricou51 ; j'essaie tant bien que mal d'aller de l'avant.
Avez-vous installer le "ping --quiet --numeric --count 3" toutes les minutes entre chez vous et une autre IP - sur RRD ? Avez-vous des pertes de paquets (depuis votre logement , êtes vous en ville ou à la campagne) ?
Histoire d'avoir des preuves de leurs incompétences ; je parle aux techniciens...... (je blaque, on les aime nos techniciens télécoms).
On attends toujours ; les reverse DNS chez Orange_FR.
Cordialement,
Romain.
-
Bonne année à toutes et à tous et meilleurs voeux pour 2026.
Essayez cela depuis vos réseaux (abonnement FAI personnel) s'il vous plaît :
MTR : My Traceroute : https://SRV.🇫🇷.◕‿◕.ST/infos/my-traceroute/ (https://SRV.🇫🇷.◕‿◕.ST/infos/my-traceroute/)
# cat /root/mtr-command.sh
# ---------------------------------------------------------------------------------------------
#!/bin/bash
# MTR : My Traceroute
# Reading MTR Output Network Diagnostic Tool : https://www.exavault.com/blog/reading-mtr-output
# Linux MTR command : https://cloudns-net.medium.com/linux-mtr-command-d1b21299dc23
# Example command : "mtr addr_IP" -> trace run for 10-15 minutes for best results.
# Other example : mtr -o 'J M X LSR NA B W V' -wzbc 50 addr_IP
# --------------------
# SRV-FR (Valdeblore ; ASN 3215 Orange S.A.) to SRV-CA (Montréal ; ASN 16276 OVHCloud)
mtr 158.69.126.137 -c 1000 -rw > /var/www/html/infos/my-traceroute/mtr-result-srv-ca-ipv4-$(date +%Y%m%d-%H%M00-GMT%z).txt &
# SRV-FR (Valdeblore ; ASN 3215 Orange S.A.) to DNS-GOOGLE (Mountain View ; ASN 15169 Google LLC)
mtr 8.8.8.8 -c 1000 -rw > /var/www/html/infos/my-traceroute/mtr-result-dns-google-ipv4-$(date +%Y%m%d-%H%M00-GMT%z).txt &
# crontab -l
# m h dom mon dow command
#minute (0-59)
#| hour (0-23)
#| | day of the month (1-31)
#| | | month of the year (1-12)
#| | | | day of the week (0-6 with 0=Sun)
#| | | | | commands
#| | | | | |
# --------------------
# A Traceroute every 6 hours
0 */6 * * * sh /root/mtr-command.sh 2>/dev/null 2>&1
Cordialement,
Romain.
# Reading MTR Output Network Diagnostic Tool : https://www.exavault.com/blog/reading-mtr-output
# Linux MTR command : https://cloudns-net.medium.com/linux-mtr-command-d1b21299dc23
The Funk Chronicles: Street Soul & Hip-Hop Heat | 70s Funk Mix with Hip-Hop Vibes (https://www.youtube.com/watch?v=OoBM-SIIR7g) on channel youtube DEEP POCKET GROOVE.
-
Super ; j'ai eu une heure sans paquet perdu entre chez moi et mon serveur Canadien.
Connection on ASN 3215 Orange S.A. in Valdeblore (FR), France (UTC+1) at home, right at the very top of the mountain, the last one in the line TO Connection on ASN 16276 OVHCloud in Montreal (CA), Canada (UTC-5).
(https://zw3b.tv/pub/screens/orange/Capture%20d'%c3%a9cran%202026-01-05%20110831%20-%20Latency%20Valdeblore%20to%20Montreal.png)
CF : https://GATE.🇫🇷.◕‿◕.ST/infos/rrd-latency.html (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/rrd-latency.html)
;-)
Quel exploit ; vous allez y arriver - Qui travaille la nuit pendant que tous le monde dort ^^ ;-)
Bonne journée à tous.
-
Le souci ne vient pas d'orange, j'ai aussi des pertes avec ma connexion free et celle du taff (orange OBS).
-
Le souci ne vient pas d'orange, j'ai aussi des pertes avec ma connexion free et celle du taff (orange OBS).
Merci pour votre réponse.
Je sais bien ; cela provient de nos liaisons fibre "hors datacenters". Je supposerais ; C'est la raison pour laquelle je suggérais d'effectuer le "ping" depuis tous les endroits que chacun puissent effectuer - Vers vos serveurs ou ceux que vous préférez. En France, ou à l'étranger. Au plus près entre potes de quartiers ; d'une ville et/ou entre correspondants Internationnelement au plus loin :-D
Pour aider nos FAI/ISP dans leurs jobs (pour NOUS)... çà prendra sûrement une décennie.
Le tutoriel est celui-ci : https://calomel.org/rrdtool.html (çà crée seulement l'image ; c'est à vous de faire une page HTML ou de la stocker dans un répertoire public ; pour pouvoir coller l'URL, l'adresse de l'image dans ce Forum (comme j'ai fais plus haut).
@+
PS : Je me suis fait une page disponible depuis tous mes "potes" - par exemple la page ci-dessous est hébergée en Australie - Et le "pote" Australien (pour moi, c'est un VPS OVH dans un Data-center), lui aussi "ping --count 3 --numeric --quiet IPV4_SRV_CANADIEN"
Sur la page HTML https://VPS.🇦🇺.IP❤10.WS/infos/rrd-latency.html (https://vps.xn--e77hib.xn--ip10-mw4b.ws/infos/rrd-latency.html) c'est dans cette "partie" @WS.IP❤10.🇦🇺
---
Sinon @darkmoon
Sur votre image le saut "7" perd 26.2% plus d'autres pertes ; donc à l'arriver j'ai perdu ces paquets.... À qui appartient la machine du saut 7 ;-) --- OK ; c'est celle-ci à réparer/optimiser ; puis qu'en c'est fait on passe à la suivante ; sur un autre réseaux, d'une autre ville, d'un même FAI ; et l'autre FAI en fait de même sur son réseau etc. On va y arriver ;-)
Reading MTR Output Network Diagnostic Tool : https://www.exavault.com/blog/reading-mtr-output
Perte de paquets importante (Significant Packet Loss) :
Ce résultat indique clairement un problème de connexion grave. Une perte de paquets importante est constatée sur les derniers sauts. Si les résultats persistent ou si le problème n'est pas résolu dans l'heure, veuillez contacter l'assistance pour une analyse plus approfondie.
Pic de latence (Latency Spike) :
La latence est enregistrée dans la colonne « Dernier saut (Last) ». Un pic de latence isolé n’indique aucun problème tant que le résultat du dernier saut est inférieur à 100.
---
D'où mon commentaire 4 de cette discussion où je fais un MTR toutes les 6 heures depuis (ma connexion personnelle de chez moi - la seule que j'ai sur une réseau "Hors Data-centers") - Résultats ici : https://srv.xn--j77hya.xn--hwgz2tba.st/infos/my-traceroute/
---
En passant je me suis fais une ZW3B page Star Citizen (https://zw3b.tv/games/UCTeLqJq1mXUX5WWoNXLmOIA) et je me suis créé un compte @LAB3WORJ « Citoyen des étoiles » sans tune ^^ J'n'ai pas +150Gig de Libre sur mon disque.
Le WikipediA Star Citizen (https://fr.wikipedia.org/wiki/Star_Citizen) et le Wiki of Star Citizen (https://starcitizen.tools/) ;-)
Roberts Space Industries (https://robertsspaceindustries.com/) (RSI)
-
On s'en fiche des pertes sur les routeurs intermédiaires, ils répondent s'ils veulent et quand ils veulent, ce n'est pas leur priorité.
Ce qui est important, c'est seulement la dernière ligne, c'est à dire la destination.
-
Ce qui est important, c'est seulement la dernière ligne, c'est à dire la destination.
Ok ; Je ne sais pas trop - Comment se fait-il alors que depuis d'autres réseaux que le mien (celui d'Orange en haut de la montagne dans les Alpes), du moins, entre Data-center aucune perte de paquet sur la réponses de "ping" Latency/Lost.
Je vais mettre en place le script MTR sur les autres serveurs (en data-center) pour vérifier - mais à priori ; la réponse (simple) par la commande "ping" répond 0% de paquet Loss.
---
Un test ; une remarque :
Ci-dessous depuis le ISP Hostinger :
Thu Jan 08 01:31:37 ⛔🔜 root@hst-fr:~ # mtr -c 10 -n 193.251.131.2 (-r)
Start: 2026-01-08T01:31:51+0100
HOST: hst-fr Loss% Snt Last Avg Best Wrst StDev
1.|-- 169.254.0.1 10.0% 10 0.4 0.3 0.3 0.4 0.0
2.|-- 153.92.3.145 0.0% 10 0.4 0.4 0.3 0.5 0.0
3.|-- 153.92.2.144 0.0% 10 0.4 0.4 0.3 0.5 0.0
4.|-- 153.92.2.103 0.0% 10 1.2 0.7 0.3 1.2 0.3
5.|-- 62.115.192.178 0.0% 10 1.5 1.1 0.6 1.6 0.3
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Ci-dessous depuis le FAI Orange :
jeu. janv. 08 01:28:05 ⛔🔜 root@srv-fr:~ # mtr -c 10 -n 193.251.131.2 (-r)
Start: 2026-01-08T01:32:33+0100
HOST: srv-fr Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.106.0.254 0.0% 10 0.1 0.2 0.1 0.2 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 80.10.255.137 0.0% 10 16.5 6.5 3.3 16.5 4.1
4.|-- 193.253.86.110 0.0% 10 11.6 5.3 3.4 11.6 2.7
5.|-- 193.252.103.241 0.0% 10 5.8 6.1 5.8 6.5 0.2
6.|-- 193.252.137.54 0.0% 10 15.7 17.9 15.4 38.8 7.3
7.|-- 193.251.131.9 0.0% 10 16.1 16.0 15.6 17.6 0.6
8.|-- 193.251.240.106 0.0% 10 21.9 22.3 21.6 23.9 0.6
9.|-- 193.251.129.181 20.0% 10 15.8 17.5 15.7 28.4 4.4
10.|-- 193.251.131.2 0.0% 10 16.1 53.2 15.8 214.3 78.2
L'IPv4 "193.251.131.2" (doit être en France) un routeur d'Orange ; çà répond "100% de Loss" et n'est donc pas "joignable" par d'autres réseaux. À priori.
J'ai trouvé cette IP dans le MTR suivant : https://SRV.🇫🇷.◕‿◕.ST/infos/my-traceroute/mtr-result-dns-google-ipv4-20260107-180000-GMT+0100.txt (https://SRV.🇫🇷.◕‿◕.ST/infos/my-traceroute/mtr-result-dns-google-ipv4-20260107-180000-GMT+0100.txt) avec un Pic de latence (Latency Spike) en saut 8 dans la colonne « Dernier saut (Last) » - (MTR : depuis chez-moi vers DNS.Google).
Note de Moi-même : C'est important le "host dns.google" pour Star Citizen ;-)
---
Note de moi-même 20260108 : Connexion Orange coupé depuis ce matin 9h30 - Jusqu'au 14 janvier 2026 nous disent-ils - J'ai dû activer (à 19h30) le partage de connexion depuis mon téléphone (Free.fr).
https://SRV.🇨🇦.◕‿◕.ST/infos/rrd-latency.html (https://SRV.🇨🇦.◕‿◕.ST/infos/rrd-latency.html)
(https://zw3b.tv/pub/screens/orange/Screenshot%202026-01-08%20at%2021-00-01%20RRD%20-%20Graphs%20Latency%20-%20SRV.%f0%9f%87%a8%f0%9f%87%a6.%e2%97%95%e2%80%bf%e2%97%95.ST%20-%20Orange-down-conn-free.fr.png)
L'image n'est pas contractuelle - L'adresse IPv4 de sortie n'est pas la bonne ; ainsi que l'AS.
(https://zw3b.tv/pub/screens/orange/Screenshot%202026-01-19%20at%2022-44-23%20RRD%20-%20Graphs%20Latency%20-%20GATE.%f0%9f%87%ab%f0%9f%87%b7.%e2%97%95%e2%80%bf%e2%97%95.ST.png)
2026/01/19 : Nouvelle impression d'écran de la connexion 4G FREE.FR du haut de ma montagne ; avec 2 barres :-D
-
Salut ; re..
J'ai mis en place les routines MTR - toutes les 6 heures ; my_traceroute --count 1000 (environ 15mintes)
Depuis les hosts :
HST-FR (Paris ; ASN 47583 Hostinger)
https://hst.fr.xn--hwgz2tba.st/infos/my-traceroute/
VPS-DE (Frankfort ; ASN 16276 OVHCloud)
https://vps.de.ipv10.net/infos/my-traceroute/
VPS-UK (Londres ; ASN 16276 OVHCloud)
https://vps.uk.ipv10.net/infos/my-traceroute/
VPS-AU (Sydney ; ASN 16276 OVHCloud)
https://vps.au.ipv10.net/infos/my-traceroute/
SRV-CA (Montreal ; ASN 16276 OVHCloud)
https://srv.ca.xn--hwgz2tba.st/infos/my-traceroute/
SRV-FR (Valdeblore ; ASN 3215 Orange S.A.) - DOWN JUSQU'AU 10/02
https://srv.fr.xn--hwgz2tba.st//infos/my-traceroute/
Les sorties vont arrivées dans les répertoires ci-dessus.
À plustard.
Romain.
-
Salut la communauté,
Un petit graphique RRD (ping/latence) des mes journées - en partage de connexion 4G FREE Mobile ; une vrai galère (j'avoue, il neige mais je suis passé à plus de 1000 MS sur un ping vers one.one.one.one) contre 150 MS il y a quelques jours.
J'arrive à avoir malgré tout la OrangeTV (par l'application smartphone), Netflix, Amazon, Disney en 4G c'est déjà bien, un peu compliqué, un peu de lag, un peu de plantage mais çà fonctionne jusqu'à ma télévision en passant par le Wi-Fi jusqu'à la clé Google Cast HDMI/Wi-Fi ;)
Ma, la fibre Orange est coupée depuis le 08/01/2026 et la remise en service a été repoussé jusqu'au 25/02/2026 jusqu'à présent.
@+
-
J'ai fini par réaliser une chose après avoir de gros lag sur Gemini en soirée
USA 360 millions habitants environ, 19h France = sortie bureau repas 13h côte est New York etc...
La côte est contient la plus grosse tranche de population des USA, et de l'autre coté à l'ouest Los Angeles c'est le matin/début de journée, en gros c'est saturation compléte en soirée chez nous.
D'ailleurs la seul IA à prévenir à ce sujet en mode gratuit à ma connaissance est Grok pendant la génération d'image un message de "pic" avec horaire s'affiche.
-
Salut ;
Au fait : monsieur @fp001 çà fonctionne mieux ?
@internetmatuer .... moi aussi.
:-\
Ici en haut de ma montagne ; c'est de pire en pire ; çà coupe ; çà envoie des SMS d’interruptions (sur 10 jours) après la remise en service 8 jours avant la soit disant remise en service - je ne comprend plus rien ^^ Merci à Orange_FR malgré tout ces soucis de connexions.
Graphiques RRD Latency : https://gate.fr.xn--hwgz2tba.st/infos/rrd-latency.html
Bonne fin de journée.
-
Par exemple sur un de mes site web ; le .FR qui est hébergé dans un datacenter en France (HST.🇫🇷.◕‿◕.ST) à Paris (et non pas sur le SRV.🇨🇦.◕‿◕.ST de Montréal) ;
Les pertes de paquets sur ma connexion Fibre Optique n'arrive même pas à récupérer un mini script Ajax -- celui de ma UNE qui doit retourner les dernières vidéos Youtube....
Avec l'Airbox ; j'ai bien mes vignettes qui s'actualisent toutes les 6 minutes.
---
Même dans Facebook en Fibre Optique par exemple ; Appeler une entité ; une ville ; une ami @name fonctionne mal (je sais bien que ce n'est pas Facebook qui déconne ; mais bien ma connexion).
---
La connexion fonctionne des fois (pertes de paquets) ....
Youpi ; quelques vignettes sont arrivées ... image 2.
-
Bonsoir,
Je suis toujours en mode intervention sur ma Fibre Optique où j'ai de plus en plus de pertes de paquets - jusqu'à 80% sur 1000 ping (1/seconde) en utilisant la commande "ping 1.1.1.1 -c 1000" ..
J'essaie d'avoir un truc génial "2 routeurs pour une connexion" en cas de problème - Le test est fait pour le réseau IPv4 (publique) ; depuis mes adresses LOCAL IPv4.
* routeur Livebox : 192.168.1.1 <--> 192.168.1.254 (gate.🇫🇷.◕‿◕.ST)
* routeur Airbox (ou smartphone) : 192.168.2.1 <--> 192.168.2.254 (gate.🇫🇷.◕‿◕.ST)
Sur ma "gateway : 192.168.1.254" qui est habituellement connectée à ma Livebox par l'interface "netbr0" ; j'ai configuré un bridge "usbbr0 avec l'adresse 192.168.2.254" et ai configuré des règles pour les 2 réseaux puis j'ai ajouté une passerelle en répartissant le trafic sortant entre les deux routeurs.
La doc est celle-ci : https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html
Je vous donne le rendu :
⛔🔜 root@gate:~ # brctl show
bridge name bridge id STP enabled interfaces
lanbr0 8000.eaa1ead7899a no enp1s0f0
netbr0 8000.768478e541f1 no enp4s0
srvbr0 8000.7e18ddbb3f7d no enp1s0f1
usbbr0 8000.e6e2cf0bfdc7 no enx7e63e18e8a71
wlanbr0 8000.ea5168b1130e no enp5s0
⛔🔜 root@gate:~ # grc ip -4 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
7: netbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.1.254/24 brd 192.168.1.255 scope global netbr0
valid_lft forever preferred_lft forever
8: lanbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 172.16.0.254/24 brd 172.16.0.255 scope global lanbr0
valid_lft forever preferred_lft forever
9: srvbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.106.0.254/24 brd 10.106.0.255 scope global srvbr0
valid_lft forever preferred_lft forever
21: usbbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.2.254/24 brd 192.168.2.255 scope global usbbr0
valid_lft forever preferred_lft forever
Note de Moi-même le 17/03/2026 :
Je n'ai pas activé ces "régles" (rt_tables 100 et 101) vu que je n'ai pas 2 réseaux distincts (qui devraient/doivent) utiliser leurs passerelles appropriés.
⛔🔜 root@gate:~ # ip rule
0: from all lookup local
218: from 192.168.1.254 lookup 100
219: from 192.168.2.254 lookup 101
220: from all lookup strongswan
32766: from all lookup main
32767: from all lookup default
En plus de la doc du dessus ; j'ai ajouté 2 régles "NAT MASQUERADE" à la place "d'une seule comme habituellement".
⛔🔜 root@gate:~ # grc ip -4 route show table 100
default via 192.168.1.1 dev netbr0
192.168.1.0/24 dev netbr0 scope link src 192.168.1.254
⛔🔜 root@gate:~ # grc ip -4 route show table 101
default via 192.168.2.1 dev usbbr0
192.168.2.0/24 dev usbbr0 scope link src 192.168.2.254
Note de Moi-même le 17/03/2026 :
J'ai activé ces/les 2 passerelles ; une vers "netbr0" et l'autre vers "usbbr0" et j'ai ajouté les 2 régles de MASQUERADE pour sortir.
⛔🔜 root@gate:~ # ip -4 route show
default
nexthop via 192.168.1.1 dev netbr0 weight 1
nexthop via 192.168.2.1 dev usbbr0 weight 1
10.6.42.0/24 via 10.106.0.252 dev srvbr0
10.106.0.0/24 dev srvbr0 proto kernel scope link src 10.106.0.254
10.116.0.0/24 via 10.106.0.252 dev srvbr0
10.116.42.0/24 via 10.106.0.252 dev srvbr0
10.126.0.0/24 via 10.106.0.252 dev srvbr0
10.126.42.0/24 via 10.106.0.252 dev srvbr0
172.16.0.0/24 dev lanbr0 proto kernel scope link src 172.16.0.254
192.168.1.0/24 dev netbr0 scope link
192.168.2.0/24 dev usbbr0 scope link
192.168.8.0/24 via 172.16.0.1 dev lanbr0
Mon poste en filaire RJ45 :
⛔🔜 root@gate:~ # iptables -L -vn -t nat | grep '172.16.0.142 '
6760 417K MASQUERADE 0 -- * netbr0 172.16.0.142 0.0.0.0/0
5188 416K MASQUERADE 0 -- * usbbr0 172.16.0.142 0.0.0.0/0
Mon sous-routeur Wi-Fi 6 sur MON LOCAL "OpenWRT (https://openwrt.org/)" qui donne la connexion à "Google Cast" ; mes smartphones etc.
⛔🔜 root@gate:~ # iptables -L -vn -t nat | grep '172.16.0.1 '
11488 1248K MASQUERADE 0 -- * usbbr0 172.16.0.1 0.0.0.0/0
11781 1088K MASQUERADE 0 -- * netbr0 172.16.0.1 0.0.0.0/0
Cà fonctionne du réseau local 172.16.0.0/24 connecté sur "lanbr0".
Pour le NAT en entrant ; l'option DMZ ou Filter NAT ne fonctionne pas sur la Airbox ; je n'ai pas pût esssayer - CF le commentaire suivant.
Le nouveau GL.iNet Beryl 7 (GL-MT3600BE) - OpenWRT ! WiFi 7 - 2.5g Ethernet ☺️ €144,19 (https://store-eu.gl-inet.com/products/beryl-7-gl-mt3600be-dual-band-wi-fi-7-travel-router)
J'avoue que c'est bizarre pour le moment ; il faut que je vérifie quelques jours si çà fonctionne mieux ou pas (pour l'instant çà rame autant ; mais çà répond). Il faut que j'ajuste mes graphiques RRD.
Depuis ma "gate.fr" Linux avec la commande "iptraf-ng"
iptraf-ng multiple uplinks 2026-03-02
https://www.youtube.com/watch?v=Cv_dvgEXqnk
;-)
Romain.
---
Note at 03h40 - Pour le moment :
Sortie Fibre Optique (6.338 MS) :
⛔🔜 root@gate:~ # ip route get 1.1.1.1
1.1.1.1 dev netbr0 src 192.168.1.254 uid 0
cache
⛔🔜 root@gate:~ # ping 1.1.1.1 -c 4
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=7.12 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=6.12 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=6.02 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=6.09 ms
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 6.022/6.338/7.124/0.455 ms
Sortie 4G (58.117 MS) :
⛔🔜 root@gate:~ # ip route get 8.8.8.8
8.8.8.8 dev usbbr0 src 192.168.2.254 uid 0
cache
⛔🔜 root@gate:~ # ping 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=110 time=63.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=62.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=60.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=110 time=46.0 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 46.020/58.117/63.470/7.043 ms
Depuis le réseau local ; j'ai encore des problèmes ; çà marche plus ou moins ; j'ai des adresses IPv4 qui sortent et d'autres non ; je ne comprend pas.
- Du et sur le smartphone "Netflix, "Amazon prime" et "Disney" fonctionne mais j'ai (mon Google Cast) seulement réussis à avoir "Netflix" sur ma Télévision ; mon smartphone est connecté à l'OpenWRT sur sa prise WAN "172.16.0.1"
- De mon PC Win11 "172.16.0.142" rien ne sort en IPv4 (sauf google.com).
Pourtant je vois du trafic NAT Masqué depuis cette machine.
⛔🔜 root@gate:~ # iptables -L -vn -t nat | grep '172.16.0.142 '
381 27660 MASQUERADE 0 -- * netbr0 172.16.0.142 0.0.0.0/0
98 24081 MASQUERADE 0 -- * usbbr0 172.16.0.142 0.0.0.0/0
@+
CF :
C:\Users\ORJ>ping -4 google.com
Envoi d’une requête 'ping' sur google.com [172.217.18.110] avec 32 octets de données :
Réponse de 172.217.18.110 : octets=32 temps=233 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=166 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=58 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=53 ms TTL=109
Statistiques Ping pour 172.217.18.110:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 53ms, Maximum = 233ms, Moyenne = 127ms
C:\Users\ORJ>ping -4 yahoo.com
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.163] avec 32 octets de données :
Réponse de 98.137.11.163 : octets=32 temps=513 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=248 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=207 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=218 ms TTL=41
Statistiques Ping pour 98.137.11.163:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 207ms, Maximum = 513ms, Moyenne = 296ms
C:\Users\ORJ>ping -4 zw3b.fr
Envoi d’une requête 'ping' sur zw3b.fr [147.79.115.130] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 147.79.115.130:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\ORJ>ping -4 zw3b.tv
Envoi d’une requête 'ping' sur zw3b.tv [158.69.126.137] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 158.69.126.137:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\ORJ>ping -4 lafibre.info
Envoi d’une requête 'ping' sur lafibre.info [80.67.167.77] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 80.67.167.77:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
EXTRA-ORDINAIRE - Et ce ne sont pas les mêmes adresses IPv4 de destination :
C:\Users\ORJ>ping -4 google.com
Envoi d’une requête 'ping' sur google.com [142.251.142.78] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 142.251.142.78:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\ORJ>ping -4 yahoo.com
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.164] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 98.137.11.164:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
humm..
Envoi d’une requête 'ping' sur google.com [142.251.142.78]
C:\Users\ORJ>ping 142.251.142.78
Envoi d’une requête 'Ping' 142.251.142.78 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 142.251.142.78:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
⛔🔜 root@gate:~ # ip r g 142.251.142.78
142.251.142.78 dev usbbr0 src 192.168.2.254 uid 0
cache
Envoi d’une requête 'ping' sur google.com [172.217.18.110]
C:\Users\ORJ>ping 172.217.18.110
Envoi d’une requête 'Ping' 172.217.18.110 avec 32 octets de données :
Réponse de 172.217.18.110 : octets=32 temps=571 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=58 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=51 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=160 ms TTL=109
Statistiques Ping pour 172.217.18.110:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 51ms, Maximum = 571ms, Moyenne = 210ms
⛔🔜 root@gate:~ # ip r g 172.217.18.110
172.217.18.110 dev netbr0 src 192.168.1.254 uid 0
cache
# --------------------------------
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.163]
C:\Users\ORJ>ping 98.137.11.163
Envoi d’une requête 'Ping' 98.137.11.163 avec 32 octets de données :
Réponse de 98.137.11.163 : octets=32 temps=901 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=217 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=251 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=295 ms TTL=41
Statistiques Ping pour 98.137.11.163:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 217ms, Maximum = 901ms, Moyenne = 416ms
⛔🔜 root@gate:~ # ip r g 98.137.11.163
98.137.11.163 dev netbr0 src 192.168.1.254 uid 0
cache
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.164]
C:\Users\ORJ>ping 98.137.11.164
Envoi d’une requête 'Ping' 98.137.11.164 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 98.137.11.164:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
⛔🔜 root@gate:~ # ip r g 98.137.11.164
98.137.11.164 dev usbbr0 src 192.168.2.254 uid 0
cache
hé hé hé ... c'est un BUG de routage dans la AIRBOX ou DANS le SATELLITE DANS L'ESPACE !!
Je vote pour le satellite dans l'espace - Analyse technique entre 00h38 et 04h36
Vraiment bizarre parce que depuis la passerelle elle-même tout fonctionne.
----
Alors là c'est la meilleur :
Propriétaire en mon nom sur ma ligne Orange_FR (France Télécom) et propriétaire en mon nom sur mon serveur OVH au Canada.
⛔🔜 root@gate:~ # ping 158.69.126.137 -I netbr0 -c 10
PING 158.69.126.137 (158.69.126.137) from 192.168.1.254 netbr0: 56(84) bytes of data.
--- 158.69.126.137 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9193ms
⛔🔜 root@gate:~ # ping 158.69.126.137 -I usbbr0 -c 10
PING 158.69.126.137 (158.69.126.137) from 192.168.2.254 usbbr0: 56(84) bytes of data.
64 bytes from 158.69.126.137: icmp_seq=1 ttl=40 time=144 ms
64 bytes from 158.69.126.137: icmp_seq=3 ttl=40 time=236 ms
64 bytes from 158.69.126.137: icmp_seq=4 ttl=40 time=280 ms
64 bytes from 158.69.126.137: icmp_seq=5 ttl=40 time=209 ms
64 bytes from 158.69.126.137: icmp_seq=7 ttl=40 time=130 ms
64 bytes from 158.69.126.137: icmp_seq=8 ttl=40 time=138 ms
64 bytes from 158.69.126.137: icmp_seq=10 ttl=40 time=127 ms
--- 158.69.126.137 ping statistics ---
10 packets transmitted, 7 received, 30% packet loss, time 9013ms
rtt min/avg/max/mdev = 126.537/180.517/280.005/56.499 ms
C'est fou.. Ils sont vraiment dingue ces tech.OS d'Orange ... çà doit être pour me faire hié... (je suis en période "Intervention"). C'est pas sympat ; il faut remettre la ligne de routage "de moi à moi" le soir avant de partir du taf ; faut pas oublier demain.
En plus je les chauffe au "3900" en donnant mon pseudo de "lafibre.info" ; ils ne connaissent pas me disent-ils ... Faut-essayer les gars, mesdames, messieurs.
:-)
Merci.
-
Salut,
Connexion Fibre Optique via Livebox encore Hors Service.
J'ai activé l'option "Sécurité > DMZ" d'une Airbox 4 - 4G d'Orange ; mais çà ne fonctionne pas, ainsi que "Sécurité > Filter - (le NAT)" ; Ni les SMS en passant.
Et pour vous, avez-vous essayé ?
- Software Version: MW45_QA_02.00_18
- Device Name: MW45
⛔🔜 root@gate:~ # lsusb -v
Bus 005 Device 004: ID 1bbb:0908 T & A Mobile Phones Mobilebroadband
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1bbb T & A Mobile Phones
idProduct 0x0908
bcdDevice 2.42
iManufacturer 1 Alcatel
iProduct 2 Mobilebroadband
iSerial 3 1234567890ABCDE
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x006f
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 6 Ethernet Networking
bFunctionProtocol 0
iFunction 9 CDC ECM
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0
iInterface 6 CDC Ethernet Control Model (ECM)
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 7 1afe0759c803
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 8 CDC Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 4 Mass Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
⛔🔜 root@gate:~ # udevadm info --name=/dev/disk/by-id/usb-ONETOUCH_MobileBroadBand_1234567890ABCDE-0:0
P: /devices/pci0000:00/0000:00:1d.7/usb5/5-3/5-3:1.2/host4/target4:0:0/4:0:0:0/block/sdb
M: sdb
U: block
T: disk
D: b 8:16
N: sdb
L: 0
S: disk/by-path/pci-0000:00:1d.7-usb-0:3:1.2-scsi-0:0:0:0
S: disk/by-diskseq/5037
S: disk/by-id/usb-ONETOUCH_MobileBroadBand_1234567890ABCDE-0:0
Q: 5037
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb5/5-3/5-3:1.2/host4/target4:0:0/4:0:0:0/block/sdb
E: DEVNAME=/dev/sdb
E: DEVTYPE=disk
E: DISKSEQ=5037
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: USEC_INITIALIZED=130745512198
E: ID_BUS=usb
E: ID_MODEL=MobileBroadBand
E: ID_MODEL_ENC=MobileBroadBand\x20
E: ID_MODEL_ID=0908
E: ID_SERIAL=ONETOUCH_MobileBroadBand_1234567890ABCDE-0:0
E: ID_SERIAL_SHORT=1234567890ABCDE
E: ID_VENDOR=ONETOUCH
E: ID_VENDOR_ENC=ONETOUCH
E: ID_VENDOR_ID=1bbb
E: ID_REVISION=2.31
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_USB_MODEL=MobileBroadBand
E: ID_USB_MODEL_ENC=MobileBroadBand\x20
E: ID_USB_MODEL_ID=0908
E: ID_USB_SERIAL=ONETOUCH_MobileBroadBand_1234567890ABCDE-0:0
E: ID_USB_SERIAL_SHORT=1234567890ABCDE
E: ID_USB_VENDOR=ONETOUCH
E: ID_USB_VENDOR_ENC=ONETOUCH
E: ID_USB_VENDOR_ID=1bbb
E: ID_USB_REVISION=2.31
E: ID_USB_TYPE=disk
E: ID_USB_INSTANCE=0:0
E: ID_USB_INTERFACES=:020600:0a0000:080650:
E: ID_USB_INTERFACE_NUM=02
E: ID_USB_DRIVER=usb-storage
E: ID_PATH=pci-0000:00:1d.7-usb-0:3:1.2-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_1d_7-usb-0_3_1_2-scsi-0_0_0_0
E: DEVLINKS=/dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.2-scsi-0:0:0:0 /dev/disk/by-diskseq/5037 /dev/disk/by-id/usb-ONETOUCH_MobileBroadBand_1234567890ABCDE-0:0
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:
⛔🔜 root@gate:~ # lshw -short
Chemin matériel Périphérique Classe Description
====================================================================
system Aspire X1920 (To Be Filled By O.E.M.)
/0 bus Aspire X1920
/0/0 memory 64KiB BIOS
/0/4 processor Pentium(R) Dual-Core CPU E6700 @ 3.20GHz
/0/4/5 memory 64KiB L1 cache
/0/4/6 memory 2MiB L2 cache
/0/10 memory 4GiB Mémoire Système
/0/10/0 memory 2GiB DIMM DDR3 Synchrone 1066 MHz (0,9 ns)
/0/10/1 memory 2GiB DIMM DDR3 Synchrone 1066 MHz (0,9 ns)
/0/100 bridge 4 Series Chipset DRAM Controller
/0/100/1 bridge 4 Series Chipset PCI Express Root Port
/0/100/1/0 enp1s0f0 network NetXtreme II BCM57810 10 Gigabit Ethernet
/0/100/1/0.1 enp1s0f1 network NetXtreme II BCM57810 10 Gigabit Ethernet
/0/100/2 /dev/fb0 display 4 Series Chipset Integrated Graphics Controller
/0/100/1b card0 multimedia NM10/ICH7 Family High Definition Audio Controller
/0/100/1b/0 input10 input HDA Intel Line Out
/0/100/1b/1 input11 input HDA Intel Front Headphone
/0/100/1b/2 input6 input HDA Digital PCBeep
/0/100/1b/3 input7 input HDA Intel Rear Mic
/0/100/1b/4 input8 input HDA Intel Front Mic
/0/100/1b/5 input9 input HDA Intel Line
/0/100/1c bridge NM10/ICH7 Family PCI Express Port 1
/0/100/1c/0 bridge ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
/0/100/1c/0/3 bridge ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
/0/100/1c/0/3/0 enp4s0 network RTL8125 2.5GbE Controller
/0/100/1c/0/7 bridge ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
/0/100/1c/0/7/0 enp5s0 network RTL8125 2.5GbE Controller
/0/100/1c.2 bridge NM10/ICH7 Family PCI Express Port 3
/0/100/1c.2/0 enp6s0 network RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
/0/100/1d bus NM10/ICH7 Family USB UHCI Controller #1
/0/100/1d/1 usb1 bus UHCI Host Controller
/0/100/1d.1 bus NM10/ICH7 Family USB UHCI Controller #2
/0/100/1d.1/1 usb2 bus UHCI Host Controller
/0/100/1d.2 bus NM10/ICH7 Family USB UHCI Controller #3
/0/100/1d.2/1 usb3 bus UHCI Host Controller
/0/100/1d.3 bus NM10/ICH7 Family USB UHCI Controller #4
/0/100/1d.3/1 usb4 bus UHCI Host Controller
/0/100/1d.7 bus NM10/ICH7 Family USB2 EHCI Controller
/0/100/1d.7/1 usb5 bus EHCI Host Controller
/0/100/1d.7/1/3 scsi4 communication Mobilebroadband
/0/100/1d.7/1/3/0.0.0 /dev/sdb disk MobileBroadBand
/0/100/1d.7/1/3/0.0.0/0 /dev/sdb disk
/0/100/1d.7/1/8 scsi5 storage USB2.0-CRW
/0/100/1d.7/1/8/0.0.0 /dev/sdc disk Multi-Card
/0/100/1d.7/1/8/0.0.0/0 /dev/sdc disk
/0/100/1e bridge 82801 PCI Bridge
/0/100/1f bridge 82801GB/GR (ICH7 Family) LPC Interface Bridge
/0/100/1f/0 system PnP device PNP0c01
/0/100/1f/1 system PnP device PNP0b00
/0/100/1f/2 input PnP device PNP0f03
/0/100/1f/3 system PnP device PNP0c02
/0/100/1f/4 system PnP device PNP0c02
/0/100/1f/5 system PnP device PNP0c02
/0/100/1f/6 system PnP device PNP0c02
/0/100/1f/7 system PnP device PNP0c02
/0/100/1f/8 system PnP device PNP0c01
/0/100/1f.1 storage 82801G (ICH7 Family) IDE Controller
/0/100/1f.2 scsi2 storage NM10/ICH7 Family SATA Controller [IDE mode]
/0/100/1f.2/0.0.0 /dev/sda disk 160GB SAMSUNG HM160HI
/0/100/1f.2/0.0.0/1 /dev/sda1 volume 476MiB EXT4 volume
/0/100/1f.2/0.0.0/2 /dev/sda2 volume 3815MiB Linux swap volume
/0/100/1f.2/0.0.0/3 /dev/sda3 volume 51GiB EXT4 volume
/0/100/1f.2/0.0.0/4 /dev/sda4 volume 93GiB Extended partition
/0/100/1f.2/0.0.0/4/5 /dev/sda5 volume 93GiB EXT4 volume
/0/100/1f.3 bus NM10/ICH7 Family SMBus Controller
/1 input3 input Power Button
/2 input4 input Power Button
/3 input5 input PC Speaker
/4 enx1afe0759c803 network Ethernet interface
⛔🔜 root@gate:~ # lshw -C cpu
*-cpu
description: CPU
produit: Pentium(R) Dual-Core CPU E6700 @ 3.20GHz
fabriquant: Intel Corp.
identifiant matériel: 4
information bus: cpu@0
version: 6.23.10
numéro de série: To Be Filled By O.E.M.
emplacement: CPU 1
taille: 3192MHz
capacité: 3203MHz
bits: 64 bits
horloge: 267MHz
fonctionnalités: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm cpufreq
configuration: cores=2 enabledcores=2 microcode=2571 threads=2
⛔🔜 root@gate:~ # lsmod | grep usb_storage
usb_storage 81920 2 uas,ums_realtek
scsi_mod 286720 5 sd_mod,usb_storage,uas,libata,sg
scsi_common 16384 5 scsi_mod,usb_storage,uas,libata,sg
usbcore 348160 8 ehci_pci,usbnet,usb_storage,ehci_hcd,cdc_ether,uas,ums_realtek,uhci_hcd
Les commandes de gestion des périphériques (https://blog.stephane-robert.info/docs/admin-serveurs/linux/commandes-peripheriques/) de Stéphane Robert.
J'ai essayé l'adresse de la Airbox "192.168.2.1" aussi dans le champ adresse WAN, sans succès.
Infos :
J'ai ajouté l'adresse IPv4 de la Airbox "92.184.112.227" sur mon DNS (les 2 autres IP sont mes adresses Fibre Optique et ne sont accessible actuellement) :
⛔🔜 root@gate:~ # host gate.fr.xn--hwgz2tba.st
gate.fr.xn--hwgz2tba.st has address 92.184.112.227
gate.fr.xn--hwgz2tba.st has address 90.116.205.63
gate.fr.xn--hwgz2tba.st has IPv6 address 2a01:cb1d:813:4a00::1
Test de connexion HTTPS depuis le Canada sur la Airbox / DMZ actiivée :
⛔🔜 root@srv-ca.lb1.ww1:~ # curl -I -L -v https://gate.fr.xn--hwgz2tba.st
* Trying 2a01:cb1d:813:4a00::1...
* TCP_NODELAY set
* Trying 92.184.112.227...
* TCP_NODELAY set
* connect to 2a01:cb1d:813:4a00::1 port 443 failed: Connexion terminée par expiration du délai d'attente
* connect to 92.184.112.227 port 443 failed: Connexion terminée par expiration du délai d'attente
* Trying 90.116.205.63...
* TCP_NODELAY set
* connect to 90.116.205.63 port 443 failed: Connexion terminée par expiration du délai d'attente
* Failed to connect to gate.fr.xn--hwgz2tba.st port 443: Connexion terminée par expiration du délai d'attente
* Closing connection 0
curl: (7) Failed to connect to gate.fr.xn--hwgz2tba.st port 443: Connexion terminée par expiration du délai d'attente
J'ai ces ports ouverts sur la machine "22,80,443" ; SSH et WEB...
çà ne répond pas au ping ¿ICMP? (avec le firewall de la Airbox désactivé et/ou avec la DMZ activé et/ou en NAT TCP/UDP "1-65535" vers mon routeur Linux "192.168.2.254".
---
Pour le suivis du dernier message ; çà fonctionne ;-)
Note de Moi-même : En passant j'ai écris ce "papier" sur mon GitHub My 2026 Personnal Security : Protection / Security Hard-Drive and Authentification Yubikey (https://github.com/LAB3W/docs/wiki/My-2026-Personnal-Security) pour celles et ceux que çà pourraient intéresser.
Merci,
salutations Romain.
-
Bonjour,
Le technicien France Télécom (Orange) est passé chez moi à Valdeblore (FR), France ("netbr0"). ; il a ressoudé la fibre ...
J'ai bien meilleures stats au "ping" toutes les minutes (aucune perte de paquet depuis les 2 heures de remise en service) : RRD - Graphs Latency (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/rrd-latency.html) :-: infos :-: GATE.🇫🇷.◕‿◕.ST
Pour infos ; j'avais entre 60% et 80% de pertes de paquets par journée ; la fibre optique était branchée depuis plus de 3 ans dans les Alpes Maritimes en zone climat H2 : zones intermédiaires (climat tempéré). Merci au Technicien !
Le traffic des 2 connexions Connection on ASN 3215 depuis "netbr0" (Fibre Optique) et depuis "usbbr0" (Airbox 4G) sur cette page ; MRTG (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/mrtg.html) :-: infos :-: GATE.🇫🇷.◕‿◕.ST
Pour infos ma commande pour ma "gateway" (sorties IPv4) pour prioriser "netbr0" à "usbbr0" :
ip route add default scope global nexthop via 192.168.1.1 dev netbr0 weight 10 nexthop via 192.168.2.1 dev usbbr0 weight 1
Cà m'a l'air stable ;-)
16h...
---
J'ai une question ;
Croyez-vous que je pourrais les appeler pour les remercier et "soumettre l'idée" qu'ils activent l’option DMZ des "Airbox 4 - 4G d'Orange" ; Filters NAT ; çà me ferait une 2ème IPv4 public.
Au cas où .. ou cela ne sert à rien.
::)
-
salut,
J'ai désactivé ma Airbox... pour voir les graphiques de bonnes ou mauvaises connexion..
⛔🔜 root@gate:~ # ip route del default scope global nexthop via 192.168.1.1 dev netbr0 weight 10 nexthop via 192.168.2.1 dev usbbr0 weight 1
⛔🔜 root@gate:~ # ip route add default via 192.168.1.1 dev netbr0
J'appelle demain ; j'ai déjà appelé le Teck.Os (qui a fait un bon travail) pour dire que moi et un autre abonné nous sommes dans l’indisponibilité de "communiquer" ; nous n'avons plus internet .. ou à moitié... Remise en service cette journée, ce matin, çà fonctionne 4 heures de midi à 16h.. puis DéLIRE TOTAl... plus de connexion à 16h !!
Pour moi le Technicien est passé entre 11H et 12H et a fait un super travail - CF l'image du dessous.
Qui fait quoi ; qui nous a coupé à 16h !? Ça doit venir de l'armoire ; je pense "à quelqu'un qui y aurait touché" entre 15h59 et 16h le 20/03/2026.
J'attends le graphique ; sinon je m'excuse si ma connexion only Fibre Optique ne déconne pas !
C'était correct entre 12h et 16h - Aucune perte de paquet comme sur le graphique RRD d'un "ping -c3" vers mon serveur Canadien - puis çà répartit comme en 40.
C'EST LA MERDE ; J'ai donc bien la preuve que la connexion peut être stable normalement comme sur la photo 1 ci dessous !
Explication du graphique : Ce graphique illustre le temps d'aller-retour (RTT) et la perte de paquets (PL). Le RTT est représenté en bleu. La perte de paquets est indiquée par la couleur de fond de la zone du graphique sur la période où elle a été constatée. En l'absence de perte de paquets, le fond est blanc, comme dans l'exemple. En cas de perte de paquets, le fond varie du jaune au rouge selon l'importance de la perte. Nous représentons 24 heures de données avec une granularité d'une minute ; les heures sont indiquées sur l'axe des abscisses (x) en bas du graphique. L'axe des ordonnées (y) est automatiquement gradué en fonction des données collectées et indique la latence en millisecondes (ms) ; la légende de l'axe des ordonnées est imprimée à gauche et à droite. Le titre est en noir en haut et la date et l'heure de création du graphique apparaissent en filigrane gris clair en bas. Lors de la lecture du graphique, n'oubliez pas que les données les plus récentes sont à droite et les plus anciennes à gauche.
-
J'ai d'autres preuves en plus du graphique RRD ci-dessus "ping -c3" toutes les minutes ; qui me représente qu'entre 12h et 16 heure la connexion était normale - Pendant 4 heures après l'intervention du technicien tout fonctionnait bien.
My Traceroute :
1. à 15h
* mtr-result_20260320-150000-GMT+0100_gate-fr_2_srv-ca_ipv4.txt (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/my-traceroute/2026/03/mtr-result_20260320-150000-GMT+0100_gate-fr_2_srv-ca_ipv4.txt) 2026-03-20 15:19 2.2K
2. à 21h
* mtr-result_20260320-150000-GMT+0100_gate-fr_2_srv-ca_ipv4.txt (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/my-traceroute/2026/03/mtr-result_20260320-210000-GMT+0100_gate-fr_2_srv-ca_ipv4.txt) 2026-03-20 21:16 1.8K
Le traceroute à 15h quand tout fonctionne bien :
Start: 2026-03-20T15:00:02+0100
HOST: gate Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
2.|-- 10.216.11.64 0.0% 1000 51.4 50.2 23.0 697.8 48.5
3.|-- 10.216.10.49 0.0% 1000 53.7 51.2 22.4 702.1 48.7
4.|-- 10.216.10.54 0.0% 1000 49.5 56.0 24.0 675.4 51.0
5.|-- 10.216.10.62 0.0% 1000 46.2 52.5 23.7 698.4 52.7
6.|-- 10.216.10.65 0.0% 1000 35.4 53.6 23.0 722.6 54.5
7.|-- ae31-760.ngesevir01.rbci.orange.net 0.0% 1000 57.9 52.6 22.8 723.6 54.9
8.|-- ae31-0.nclyo203.rbci.orange.net 0.0% 1000 56.2 52.8 23.9 759.6 55.5
9.|-- ae41-0.nilyo101.rbci.orange.net 0.0% 1000 50.2 53.2 22.5 785.4 56.4
10.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
11.|-- 193.251.131.2 7.8% 1000 39.5 81.9 29.4 1116. 96.8
12.|-- mrs-mrs1-pb1-ptx.fr.eu 0.0% 1000 47.0 57.3 28.1 813.0 55.1
13.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
17.|-- be103.lil1-rbx8-sbb1-nc5.fr.eu 0.1% 1000 59.9 65.8 36.4 777.6 49.8
18.|-- lon-thw-sbb1-nc5.uk.eu 0.0% 1000 65.1 70.8 41.9 759.9 49.6
19.|-- nyc-ny9-sbb1-8k.ny.us 0.0% 1000 137.0 149.3 118.7 856.4 54.5
20.|-- be102.bhs-g1-nc5.qc.ca 0.0% 1000 134.9 158.3 125.6 834.3 56.1
21.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
22.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
23.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
24.|-- mail.zw3b.eu 30.2% 1000 144.1 150.2 120.4 682.6 44.4
Le traceroute quand tout déconne :
Start: 2026-03-20T21:00:01+0100
HOST: gate Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
2.|-- 80.10.255.137 98.7% 1000 2.2 3.2 2.2 4.0 0.5
3.|-- ae105-0.ncnic202.rbci.orange.net 95.5% 1000 3.0 4.4 2.8 21.4 3.7
4.|-- ae43-0.nimar202.rbci.orange.net 75.0% 1000 5.3 5.7 4.7 17.9 1.6
5.|-- ae40-0.nimar201.rbci.orange.net 78.7% 1000 5.6 7.0 5.2 40.5 3.6
6.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
7.|-- 193.251.131.2 76.8% 1000 294.1 20.3 5.8 557.9 73.6
8.|-- mrs-mrs1-pb1-ptx.fr.eu 52.8% 1000 5.6 5.9 5.2 23.5 1.3
9.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
13.|-- be103.lil1-rbx8-sbb1-nc5.fr.eu 11.5% 1000 19.1 19.5 18.3 43.9 2.1
14.|-- lon-thw-sbb1-nc5.uk.eu 52.5% 1000 24.4 24.6 23.4 36.5 1.0
15.|-- nyc-ny9-sbb1-8k.ny.us 14.1% 999 99.1 99.8 97.5 133.4 2.3
16.|-- be102.bhs-g1-nc5.qc.ca 14.2% 998 105.4 107.6 104.5 192.7 9.9
17.|-- ??? 100.0 998 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 998 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 998 0.0 0.0 0.0 0.0 0.0
20.|-- mail.zw3b.eu 11.9% 998 104.2 104.3 103.4 129.5 1.5
On s’aperçoit que je transite par d'autres IP .... et qu'en plus ; il y a des pertes de paquets à partir du sauts "15"..
J'envoie 1000 ping toutes les 6 heures en utilisant la commande "mtr" : je devrais avoir "Snt 1000" à la fin.
Photo d'aujourd'hui CF les dates et heures sur l'image.
-
Je relance ma Airbox...
CF les graphs... dans quelques heures..
En passant par là ; les mecs chez Hostinger (http://Hostinger), ils n'ont toujours pas d'anti DDOS...
Pour celles et ceux qui voyent mes graphs MRTG ; RRD depuis mes IP internet.. (serveurs)
je vais leur faire un script de bannissement d'IP (et de contre-attaque ; pour moi-même).
L'impression d'écran du dessous 25-26/03/2026 - 1er graphique connexion Fibre Optique ; 2ème graphique Airbox 4G (toujours la galère sur ma Fibre Optique) - RRD - Graphs Latency (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/rrd-latency.html) :-: infos (https://gate.xn--j77hya.xn--hwgz2tba.st/infos/) :-: GATE.🇫🇷.◕‿◕.ST (https://gate.xn--j77hya.xn--hwgz2tba.st/)