Le répéteur a aussi eu un nouveau firmware (SR7R_fr-1.1.9.16) mais le bug de détection est toujours présent et idem pour le nom du répeteur qui revient à celui par defaut à chaque redémarrage de la livebox.

Je me demande vraiment ce que les firmwares apportent ....

- blacklist après analyse des logs

C'est déjà le cas.

- whitelist pour IPv6 et les utilisateurs connectés (rule set dynamique)

Des bots sont repérés en IPv6 dans ce forum.
Pour les utilisateurs connectés, même si Vivien ne m'a pas répondu quand j'avais remarqué publiquement une plus grande fluidité quand on est connecté, ben c'est encore le cas maintenant.. Entre 10k et 20k "visiteurs", beaucoup de lenteurs pour la moindre page en invité. Par contre, dès que je me suis connecté à mon compte, avec sensiblement le même nombre en "invités", c'est devenu très fluide pour moi.

- greylist avec rate limit pour le reste, par défaut, ou page de maintenance lorsque la charge >80%

Il y a déjà une rate limit. Mais c'est par IP. Hors les bot et les DDoS utilisent beaucoup des centaines d'IP, voir beaucoup plus.
Et mettre une page de maintenance avant les 100%, c'est donner raison aux DDoS. On les ferait gagné à 80% de la charge, en interdisant à tout le monde l'accès... sic.

- blacklist après analyse des logs
- whitelist pour IPv6 et les utilisateurs connectés (rule set dynamique)
- greylist avec rate limit pour le reste, par défaut, ou page de maintenance lorsque la charge >80%

Non ?

Dans le top des user-agent, on a des user agent de vrais navigateurs Google Chrome, mais avec 0% d'IPv6.

Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/150.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/147.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/151.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/148.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/149.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (Linux; Android 15; Pixel 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 15; CPH2653) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 15; SM-S938B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 14; 23127PN0CC) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 14; Pixel 8 Pro) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Mobile Safari/537.36

En filtrant sur ces user-agent, j'ai fait une analyse par IP avec à chaque fois l'AS associé et je tombe de haut.

On a des IPv4 qui sont presque toutes chez les 4 grands opérateurs français et quand je regarde les log sur une IP particulière, voici le trafic : 202610_log_ipv4_bouygues_etonante.txt

Ce sont des requêtes qui chargent des pages, presque toujours les mêmes, sans charger la moindre image et avec comme caractéristique le user-agent qui change à chaque requête.

Le user-agent change à chaque requête, avec un Chrome d'un iPhone ou d'un Android.
Quel est le but ? Les pages sont souvent les mêmes, donc ce n'est pas pour récupérer des données du site.

J'ai extrait une IPv4 en exemple, mais j'ai beaucoup d'IPv4 chez les 4 opérateurs qui ont ce comportement étrange qui semble typique de la volonté de faire du DDOS.

Effectivement ! Je retrouve du débit en download !
Un grand merci ! Je n'avais pas pensé à désactiver la 6Ghz. Je vais remonter au support Ubiquity.