Qu'en est il?

Le réseau est ouvert. La seule contrainte, quelque soit l'opérateur, c'est d'attendre un délai légal (1 ou 3 mois) à compter de la fin des travaux. (la date est la même quelque soit le FAI).

Free pouvait donc ouvrir son réseau le même jour que les autres FAIs. Si il y a du retard, la seule et unique cause et chez Free.

Bonjour,

Normalement cela fonctionne.
* Ne pas mettre une IP fixe sur le PC en lui-même, rester en DHCP.
* Dans l'interface de la box : Attribuer un bail sur l'adresse MAC du PC (si l'adresse n'apparait pas la dernière sélection "Equipement" permet de le rentrer à la main dans le champ) compris dans le range des adresses fournis par le serveur DHCP.
* Redémarrer la Livebox et faire un renew sur le PC.
==> À ce moment-là le PC prendra toujours la même IP.

Si le préchargement tourne autour de 400-500Mb/s et que le jeu pèse environ 200Go, en max 2h ce serait plié...
Mais des millions de consoles qui lancent le dl en même temps, c'est là, l'idée de mon post, pour moi il va y avoir des problèmes. Ce n'est que mon humble avis.

ça m'étonnerait qu'ils n'aient rien prévu. ça ne sert à rien de faire 7 jours de prétéléchargement si c'est pour "lancer" tous les téléchargements à 00h de chaque pays dès le 12 Novembre.
Il ont du prévoir quelque chose. (Comme un téléchargement différé pour justement que toutes les consoles ne lancent pas le téléchargement en même temps... Ex : seul 1 000 consoles peuvent commencer le téléchargement par tranche de 1min. Chiffre à adapter bien sur pour répartir la charge sur les 5 ou 6 premiers jours du prétéléchargement).
ou alors selon ton code/clé licence ou selon la date à laquelle tu l'as acheté le jeu/validé la clé dans ton compte, le téléchargement démarre pour s'étaler dans le temps (tout en étant OK pour le 19 à 00h00).

j'ai fait un post sur la communauté d'Orange, j'en fait une copie ici j'ai galéré un moment avant de trouver :

Livebox Wi-Fi 7 — « WPA3 Personal Compatibility » : élément RSNXE Override absent du message 3/4, les clients WPA3 sont rejetés (reason 17)
Résumé
Sur une Livebox Wi-Fi 7 réglée en WPA3 Personal Compatibility (le réglage recommandé, et obligatoire pour le Wi-Fi 7 en 2,4/5/6 GHz), un client Wi-Fi qui sait faire du WPA3 est systématiquement rejeté pendant le 4-way handshake, avec le code de déconnexion 17 — IE differs in 4-way handshake.

La cause est mesurable et précise : la Livebox annonce un élément RSNXE Override dans sa balise, mais ne le répète pas dans le message 3/4 du 4-way handshake. Le client constate la différence, en déduit une tentative de downgrade, et coupe la connexion — ce que la spécification lui demande de faire.

Les clients qui ignorent le mécanisme d'Override (anciens, WPA2 seulement) ne sont pas affectés. Ce sont donc les clients les plus récents qui échouent, et eux seuls.

Matériel et configuration
Box   Livebox Wi-Fi 7, bande 2,4 GHz, canal 1, 20 MHz
Sécurité   WPA3 Personal Compatibility (mode transition WPA2/WPA3)
Client   Module IoT à base d'Espressif ESP32-C6 (Wi-Fi 6, 2,4 GHz)
Pile logicielle   ESP-IDF 6.0.2, supplicant WPA avec WPA3-SAE et H2E activés
Signal   RSSI −71 à −73 dBm, SNR 24–26 dB — association systématiquement réussie
Le même client s'associe sans aucun incident à un point d'accès WPA2-PSK classique, au même endroit, avec un signal comparable.

Symptôme
À chaque tentative, le client :

réussit l'authentification SAE (phase auth, ~280 ms, cohérente avec un échange SAE complet) ;
réussit l'association (assoc → run) ;
est déconnecté ~20 ms plus tard, avant que la connexion ne s'établisse.
Dix tentatives consécutives, toutes identiques, puis repli en mode point d'accès :

I wifi: Connexion WiFi slot 0: <SSID> ...
I wifi: (connect)dot11_authmode:0x6, pairwise_cipher:0x3, group_cipher:0x3
I wifi: state: init -> auth (0xb0)
I wifi: state: auth -> assoc (0x0)
I wifi: state: assoc -> run (0x10)
I wifi: ifidx:0, rssi:-73, phymode(0x3, 11bgn)
I wifi: state: run -> init (0x1100)
W wifi: WiFi déconnecté (reason=17), retry 1/10...
authmode 0x6 = WPA3-PSK : le client choisit bien WPA3, comme prévu en mode transition.

Diagnostic — la mesure qui nomme la cause
Avec les journaux détaillés du supplicant activés, la cause apparaît sans ambiguïté :

D wpa: rsn override valid: gcipher=3 ucipher=3 akm=9 mac=56:ec:b0:c7:9d:32
D wpa: WPA: set AP RSN IE            - hexdump(len=22): ...
D wpa: RSN: Set AP RSNE Override element  - hexdump(len=26): dd 18 50 6f 9a 29 01 00 00 0f ac 04 ... 00 0f ac 08 cc 00
D wpa: RSN: Set AP RSNXE Override element - hexdump(len=7):  ...
...
D wpa: RSN: RSNE Override element in EAPOL-Key      - hexdump(len=26): ...
I wpa: RSNXE Override element in Beacon/ProbeResp   - hexdump(len=7):  ...
I wpa: RSNXE Override element in EAPOL-Key msg 3/4  - hexdump(len=0):
I wifi: state: run -> init (0x1100)
D wifi: Send disconnect event, reason=17
Ligne à ligne :

La Livebox publie les éléments RSN Overriding de la Wi-Fi Alliance (OUI 50 6f 9a), qui permettent d'annoncer WPA3-SAE (AKM 00 0f ac 08, PMF requis — cc 00) aux clients capables, tout en gardant un RSNE de base compatible WPA2 pour les autres. C'est le fonctionnement normal du mode « Compatibility ».
Le client les lit correctement et retient WPA3.
Le RSNE Override est bien présent dans le message 3/4 (26 octets, identique à la balise).
Le RSNXE Override, lui, est annoncé dans la balise (7 octets) et absent du message 3/4 (0 octet).
Le client compare les deux, comme l'exige la protection anti-downgrade, constate la divergence et déconnecte.

Le contrôle côté client n'est pas une erreur
Ce contrôle est celui de wpa_supplicant, repris dans ESP-IDF 6.0.2 (components/wpa_supplicant/src/rsn_supp/wpa.c) :

if ((sm->ap_rsnxe_override && !ie->rsnxe_override) || ...) {
    wpa_msg(..., "RSN: RSNXE Override element mismatch between "
                 "Beacon/ProbeResp and EAPOL-Key msg 3/4");
    wpa_sm_deauthenticate(sm, WLAN_REASON_IE_IN_4WAY_DIFFERS);
    return -1;
}
Sa raison d'être est d'empêcher un attaquant de faire croire à un client qu'un réseau ne sait faire que du WPA2. Le mécanisme d'Override exige que l'AP répète à l'identique, dans le handshake chiffré, ce qu'il a annoncé en clair dans sa balise. Une balise qui promet un RSNXE Override et un message 3/4 qui n'en contient aucun sont, du point de vue du client, indiscernables d'une attaque.

Le client fait donc exactement son travail. C'est l'AP qui se contredit entre son annonce et son handshake.

Ce qui a été écarté par la mesure
Pour éviter les fausses pistes habituelles, ces quatre hypothèses ont été testées sur le matériel et réfutées :

Mot de passe erroné — NVS effacée par un flash complet, mot de passe saisi à la main sur le portail du client : résultat identique. Un mot de passe erroné rend d'ailleurs les codes 15, 14 ou 2, jamais 17.
Incompatibilité de chiffrement — le même champ de journal apparaît sur la connexion WPA2 qui réussit.
SAE Hash-to-Element — forcé à WPA3_SAE_PWE_BOTH, firmware reconstruit et flashé : inchangé.
PMF — forcé en « required », firmware reconstruit et flashé : inchangé.
Seule la désactivation, côté client, de la prise en charge du mécanisme d'Override permet l'association. Ce contournement a été vérifié sur le matériel, et il confirme le diagnostic autant que son coût :

I wifi: connected with <SSID>, aid = 4, channel 1, BW20, bssid = 56:ec:b0:c4:b9:e2
I wifi: security: WPA2-PSK, phy: bgn, rssi: -73, cipher(pairwise:0x3, group:0x3), pmf:1
I esp_netif_handlers: sta ip: 192.168.11.65
Le client s'associe — en WPA2-PSK, sur le RSNE de base, exactement comme un équipement ancien. Le WPA3 que le mode « Compatibility » est censé apporter est donc perdu, et la protection anti-downgrade avec lui. Le BSSID (56:ec:b0:…, adresse localement administrée) confirme au passage que la box publie ces éléments depuis un BSS virtuel dédié à la transition.

Impact
Tout client récent sachant lire les éléments RSN Overriding est exclu du réseau tant que le mode « Compatibility » est actif.
Le contournement disponible côté client consiste à ignorer le mécanisme d'Override, c'est-à-dire à renoncer au WPA3 sur ce réseau et à perdre la protection anti-downgrade — un recul de sécurité imposé par un défaut de la box.
Le problème touche la configuration recommandée par Orange et obligatoire en Wi-Fi 7, donc le chemin par défaut.
Questions
Le comportement décrit — RSNXE Override annoncé dans la balise, absent du message 3/4 — est-il connu et suivi ?
Un correctif de firmware Livebox est-il prévu ?
Existe-t-il, en attendant, un réglage permettant de désactiver le mécanisme RSN Overriding sans renoncer au Wi-Fi 7 ni au WPA3 pour les clients qui le gèrent correctement ?
Tous les journaux bruts, ainsi que le détail des quatre hypothèses écartées, peuvent être fournis.