Messages récents

Pages: 1 2 [3] 4 5 6 7 8 ... 10

5G Home Orange / Perte de la connectivité IPv6 sur la Flybox 5G

« Dernier message par vivien le Aujourd'hui à 21:57:23 »

Capture N°2 : PC Ubuntu server connecté en Ethernet à la flybox 5G

La capture wireshark (0,1 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_ethernet2.pcap

Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)

Détail des IP, pour bien comprendre la capture Wireshark :

Flybox 2-5G (Model: 5G19-01W-A) Wi-Fi 6 Mac : a8:fb:40:d2:3c:4f IPv4 : 192.168.1.1 IPv6 : 2a01:cb06:805a:4e19::/64 IPv6 : 2a01:cb06:805a:4e19:0:5c:a7e9:2c01 PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connexion par Ethernet à la flybox Mac : 00:1f:29:94:ec:c8 IPv6 : 2a01:cb06:805a:4e19::793 PC HP Pavillon (Core i7-12700) : Ubuntu desktop 25.10 connexion en Wi-Fi 5 à la flybox Mac : 20:2b:20:a9:03:1f IPv4 : inet 192.168.1.18/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0 IPv6 : inet6 2a01:cb06:805a:4e19:35b6:58fc:aee3:c941/64 scope global temporary dynamic IPv6 : inet6 2a01:cb06:805a:4e19:5357:106a:e70c:65ba/64 scope global dynamic mngtmpaddr noprefixroute Route : 2a01:cb06:805a:4e19::fd4 dev wlp2s0 proto kernel metric 600 pref medium Route : 2a01:cb06:805a:4e19::/64 dev wlp2s0 proto ra metric 600 pref medium Destinations testées : free.fr 2a01:e0c:1::1 (ping utilisé depuis PC HP Pavillon) ip.lafibre.info 2001:bc8:610:f:7ec2:55ff:fea9:6d88

5G Home Orange / Perte de la connectivité IPv6 sur la Flybox 5G

« Dernier message par vivien le Aujourd'hui à 21:54:41 »

Capture N°1 : PC Ubuntu server connecté en Ethernet à la flybox 5G

La capture wireshark (0,4 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_ethernet1.pcap

Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)

Détail des IP, pour bien comprendre la capture Wireshark :

Flybox 2-5G (Model: 5G19-01W-A) Wi-Fi 6 Mac : a8:fb:40:d2:3c:4f IPv4 : 192.168.1.1 IPv6 : 2a01:cb09:801a:2aee::/64 IPv6 : 2a01:cb09:801a:2aee:0:37:8af4:4501 PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connexion Ethernet à la flybox Mac : 00:1f:29:94:ec:c8 IPv4 : inet 192.168.1.14/24 metric 100 brd 192.168.1.255 scope global dynamic ens1 IPv6 : inet6 2a01:cb09:801a:2aee::793/128 scope global dynamic noprefixroute IPv6 : inet6 2a01:cb09:801a:2aee:21f:29ff:fe94:ecc8/64 scope global dynamic mngtmpaddr noprefixroute Route : 2a01:cb09:801a:2aee::/64 dev ens1 proto ra metric 100 expires 85982sec pref medium PC HP Pavillon (Core i7-12700) : Ubuntu desktop 22.10 connexion en Wi-Fi 5 à la flybox Mac : 20:2b:20:a9:03:1f IPv4 : inet 192.168.1.18/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0 IPv6 : inet6 2a01:cb09:801a:2aee:4b84:430a:1b2a:7dd7/64 scope global temporary dynamic IPv6 : inet6 2a01:cb09:801a:2aee:d9b5:3d2a:34d:d8fb/64 scope global dynamic mngtmpaddr noprefixroute Route : 2a01:cb09:801a:2aee::fd4 dev wlp2s0 proto kernel metric 600 pref medium Route : 2a01:cb09:801a:2aee::/64 dev wlp2s0 proto ra metric 600 pref medium Google Pixel 6 : Android 16 connexion en Wi-Fi 6 à la flybox Mac : 16:00:9b:c6:be:52 IPv4 : 192.168.1.99 IPv6 : 2a01:cb09:801a:2aee:7f1:923e:6f1a:b543 Destinations testées : free.fr 2a01:e0c:1::1 (ping utilisé depuis PC HP Pavillon) ip.lafibre.info 2001:bc8:610:f:7ec2:55ff:fea9:6d88

Chronologie des échanges :
T= 0,00 => 1,66 : Echanges SSH en IPv4 pour lancer la capture réseau T= 1,66 => 144,33 : Absence de trafic T= 144,96 => 145,00 : execution de "sudo netplan apply" pour activer "accept-ra: true" T= 146,35 => 147,34 : Procédure RA pour récupérer une connectivité IPv6 T= A partir de 148,6 : On voit des paquets IPv6 TCP et QUIC à desination du PC Ubuntu desktop ( 2a01:cb09:801a:2aee:4b84:430a:1b2a:7dd7 ) qui lui a perdu la connectivité IPv6. SI l'adresse IP de la destination est celle du PC Ubuntu desktop, l'adresse MAC de destination est celle du PC Ubuntu server. T= A partir de 215,3 : On voit des paquets IPv6 TCP et QUIC à desination du Pixel 6 ( 2a01:cb09:801a:2aee:7f1:923e:6f1a:b543 ) qui lui a perdu la connectivité IPv6. La mac de destination ne coorrespond pas au Pixel 6. T = 223,36 => 223,45 : Requete vers du PC Ubuntu server vers ipv4.lafibre.info en http (permet de voir l'IPv4 publique). Cela part en IPv6, cr il y a un DNS64 T = 234,02 => 234,11 : Requete vers du PC Ubuntu server vers ipv6.lafibre.info en http T = 354,61 => 357,65 : Ping ICMPv6 vers ip.lafibre.info T = 493,18 => 496,25 : Ping ICMPv6 du PC Ubuntu desktop vers le PC Ubuntu server

Détail de la configuration IP du PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connecté en Ethernet à la flybox :

5G Home Orange / Perte de la connectivité IPv6 sur la Flybox 5G

« Dernier message par vivien le Aujourd'hui à 21:49:01 »

Perte de la connectivité IPv6 : C'est un bug SLAAC (Stateless Address Autoconfiguration) de la box Nokia qui envoie les paquets IPv6 au mauvais terminal

J'ai avancé sur ce problème de perte d'IPv6 : le trafic IPv6 de toute la box va être envoyé à un même équipement (généralement un mobile Android).

Exemple : Une flybox connectée à 5 terminaux. Le terminal qui aspire tout le trafic est le terminal 2.
Les paquets émis par le terminal 1 vont aller sur internet. La réponse provenant d'internet ne va pas revenir au terminal 1, mais au terminal 2 qui va mettre à la poubelle ces paquets qu'il n'a pas demandés.
Conséquence : les terminaux 1, 3, 4 et 5 vont récupérer une IPv6 qui ne fonctionne pas.

Comme Orange a mis un DNS64, un nom de domaine IPv4 sera annoncé en IPv6 : même le trafic IPv4 souhaite partir via une IPv6 qui ne fonctionne pas. Cela ne bloque pas tout l'accès à internet, car les navigateurs web et certaines applications qui intègrent un "fall back" vers IPv4. Quand le fall back est présent sur l'application, le trafic va partir en IPv4 (la box va l'encapsuler dans une IPv6, mais l'essentiel, c'est cela fonctionne). Quand l'application n'intègre pas de fallback, l'application ne fonctionne pas.

Jusqu'à présent, j'avais du mal à reproduire le problème : je redémarrais ma flybox et je récupérais IPv6. Mon smartphone, un Pixel 6 sous Android 16, ne déclenchant pas systématiquement le bug.

J'ai trouvé un systéme d'exploitation qui permet de reproduire systématiquement le bug : Ubuntu server 25.10.
- Ubuntu avec interface graphique ⇒ Le moteur par défaut est NetworkManager : Il ne déclenche jamais le bug de la flybox Nokia.
- Ubuntu sans interface graphique ⇒ Le moteur par défaut est systemd-networkd : La perte est systématique dès qu'on a "accept-ra: true" dans la configuration Netplan (RA pour Router Advertisements, c'est l'auto-configuration SLAAC).

J'ai essayé plusieurs PC, 100% de réussite avec systemd-networkd et SLAAC ! Cela fonctionne aussi bien en Ethernet qu'en Wi-Fi (oui, on peut connecter Ubuntu server au Wi-Fi, tutoriel : Configuration du Wi-Fi avec Netplan (PC sans interface graphique).
Tout le contenu du tutoriel est réalisé avec le PC qui m'a servi pour réaliser les captures ci-dessous.

Les captures ci-dessous commencent par une capture du trafic avec accept-ra: false

Exemple de configuration utilisée pour une connexion Wi-Fi : (IPv6 est désactivé)

Code: [Sélectionner]

network:
  version: 2
  renderer: networkd
  ethernets: {}
  wifis:
    wlp16s0:
      dhcp4: true
      dhcp6: false
      accept-ra: false
      access-points:
        "Flybox-3C4F":
          password: "Y7tEEFsQUkkE"

La commande sudo tcpdump -i ens1 -n -s 0 -w /tmp/capture/ethernet.pcap ou sudo tcpdump -i wlp16s0 -n -s 0 -w /tmp/capture/wifi.pcap est lancée depuis une connexion SSH, ce qui fait que les premiers paquets de la capture Wireshark correspondent à cette connexion SSH.

Je laisse tourner deux minutes la capture (sans rien faire) sans connectivité IPv6, puis (localement sur le PC pour ne pas générer de trafic SSH), je modifie la configuration avec accept-ra: false changé pour accept-ra: true
Je fait un sudo netplan apply pour appliquer la nouvelle configuration qui active IPv6 SLAAC (Stateless Address Autoconfiguration).

Cela entraîne une nouvelle requête DHCP en IPv4, puis l'activation de l'IPv6 SLAAC qui va poser un problème et immédiatement les autres PC perdent IPv6. On le voit dans les captures, j'ai immédiatement du trafic qui est destiné au PC HP et à mon Pixel 6.
Je laisse tourner encore quelques minutes la capture.

On observe alors que de nombreux paquets IPv6 qui ne nous sont pas destinées arrivent sur notre PC avec l'adresse mac du PC, mais des adresses IP qui correspondent à d'autres PC connectés à la box. Ces derniers ne reçoivent plus les paquets IPv6, malgré de nombreuses relances.

Voici les informations sur le PC sous Ubuntu server, qui va aspirer les paquets IPv6 des autres terminaux. C'est un PC classique (j'ai testé également avec des serveurs Dell et IBM, mais ils n'avaient pas de Wi-Fi).

Actus SFR Altice / Patrick Drahi envisage de vendre SFR

« Dernier message par jacobaci le Aujourd'hui à 21:26:35 »

A été mené par qui ?
Les français veulent savoir
5 semaines, vu le morceau, c'est bien....

Actus SFR Altice / Patrick Drahi envisage de vendre SFR

« Dernier message par Philoutix le Aujourd'hui à 21:21:23 »

Patrick Drahi obtient une due diligence express et accélère sur la vente de SFR

Selon les informations de La Lettre, la procédure destinée à vérifier la santé financière de la filiale d'Altice France a été menée en cinq semaines seulement. Le consortium composé d'Orange, de Free et de Bouygues Telecom devrait présenter une offre ferme d'ici à la fin avril. Comme l'Élysée, tous les protagonistes du dossier veulent boucler la vente avant la présidentielle de 2027.

https://www.lalettre.fr/fr/entreprises_tech-et-telecoms/2026/02/09/patrick-drahi-obtient-une-due-diligence-express-et-accelere-sur-la-vente-de-sfr,110624303-art

Actus SFR Altice / Nouvelle fuite de données chez SFR : 3,6 millions de clients touchés et 150 000

« Dernier message par jacobaci le Aujourd'hui à 21:14:01 »

Une des suites d'une fuite de données

Le gars fait un beau mail et un super site pour choper votre CB (frais de livraison de votre cadeau fidélité)

Alors que dès le départ son adresse mail est pourrie....

Technologie mobile 4G / 4G/4G+/4G++: Agrégation des porteuses

« Dernier message par renaud07 le Aujourd'hui à 20:52:39 »

À priori, même un S25 ultra n'agrège pas 5 bandes différentes, on peut monter à 6 mais c'est de l'intra bande par ex : 28-7-3-3-1-1 + NR.

Et l'intra bande a bien existé chez nous : ça s'appelait la 3G 2100.

Citation de: turold le Aujourd'hui à 18:59:03

Dans le 1er cas, les bandes 700 et 800 n'ont pas d’intérêt en terme de débit d’être agrégé entre eux.

Pas tout à fait d'accord : c'est utile sur les sites ZB, se priver de 150 Mbps (voir + selon la modulation), c'est pas rien. Si en plus une des bandes plus occupée que l'autre, ça permet de compenser.

Un exemple de l'année dernière : 34 Mbps en 800, 23 Mpbs en 700 (il faudrait que j'aille au pied d'un site voir combien je pourrais tirer)

Actus Orange / Augmentation des débits sur la fibre Orange

« Dernier message par lexwllever le Aujourd'hui à 20:43:52 »

Citation de: TI@RY le Aujourd'hui à 18:39:06

Bonsoir,

Opération de maintenance "classique" non liée à une augmentation de débit vers le XGSPON, car cette commune est déjà couverte et ouverte en XGSPON au travers des abonnements Orange.

Bonne soirée.

Tu ne sais pas comment savoir ma date exacte non ?

Incidents Bouygues / Panne étonnante Bouygues

« Dernier message par buddy le Aujourd'hui à 20:40:27 »

@vous 2, Tant mieux si maintenant les techniciens ont les informations, c'est juste que c'est surprenant pour le coup d'être appelé directement sur son mobile sans préavis. Et avec les nombreuses fuites de données ... J'aimerais bien avoir la confirmation de stlan pour le coup

Citation de: 970Adsl le Aujourd'hui à 20:10:37

2) Pour moi c'était juste un hasard d'avoir le retour de la box

Alors le coup de chance j'y crois très moyen ...
Un technicien jeudi avec intervention chez moi et n'arrive pas à faire remonter le lien ..
Un technicien vient samedi et idem...
Lundi soir à 18h30 j’éteins la box 10 min pour réparer une prise et comme par hasard elle resynchronise alors qu'elle était toujours en S1 à 18h30 et 18h45 tout est fonctionnel. Un technicien serait donc passé juste à 18h35 ? (alors que j'ai un RDV prévu demain ?). Je mettrai quand même une petite pièce sur "LE firmware était planté sur S1 et le reboot électrique l'a relancé".

Incidents Bouygues / Panne étonnante Bouygues

« Dernier message par Antoinel le Aujourd'hui à 20:29:29 »

C'est probablement la généralisation de ce dispositif : https://www.corporate.bouyguestelecom.fr/archives-communique-presse/groupe-interopfibre-bouygues-telecom-orange-et-sfr-transforment-les-interventions-avec-e-intervention/

(une app commune entre les différents opérateurs (sauf Free) pour gérer les déconnexions du PM pendant une intervention)

Pages: 1 2 [3] 4 5 6 7 8 ... 10