Bonjour,

Merci hwti pour ta piste sur les canaux. C’est elle qui m’a fait creuser, et elle m’a permis d’aller au bout de l’analyse.

Ma configuration :

Livebox 7, port 10G relié à un switch 2,5G qui dessert toutes les prises RJ45 de la maison ;
répéteur Wi-Fi 7 Orange (Sercomm, firmware SR7R_fr_1.19.16) branché en Ethernet sur sa prise 2,5G ;
liaison vérifiée à 2,5 Gb/s (voyants vert + jaune sur le répéteur), et le PC fixe en Ethernet sur le même switch sort 2,4 Gb/s.

Le câblage est donc hors de cause.

Les débits avec un iPhone 17 Pro Max (Wi-Fi 7, 160 MHz max) :

sur la Livebox (160 MHz) : 1 741 Mb/s ;
sur le répéteur (80 MHz) : environ 940 Mb/s en réception et 900 en envoi.

Ce qu’indiquent les balises Wi-Fi (Acrylic Wi-Fi Analyzer) :

Livebox en canal auto : la Livebox est sur 100 à 128 en 160 MHz, le répéteur sur 100 à 112 en 80 MHz, avec le même canal principal.
Livebox forcée sur le canal 36 (36 à 64 en 160 MHz) via LiveboxMonitor : le répéteur reste sur 100 à 112 en 80 MHz, alors que le bloc 100 à 128 est entièrement libre (un seul voisin, à -98 dBm).
Répéteur redémarré : il suit la Livebox sur 36 à 48, toujours en 80 MHz.

Conclusion : le répéteur se cale toujours sur le canal principal de la Livebox, et il annonce 80 MHz dans tous les cas, même quand un bloc de 160 MHz est libre et qu’il est raccordé en Ethernet. Ce n’est ni une question d’interférences ni une question de chevauchement avec la Livebox. C’est la gestion imposée par Orange.

Au passage, avec la Livebox sur 36, le signal du répéteur baissait d’environ 8 dB (de -46 à -54 dBm). Ça colle avec la puissance plus élevée autorisée sur les canaux 100 à 140. Je suis donc revenu en canal auto.

J’avoue que j’ai les boules : j’ai pris ce répéteur précisément pour son port 2,5G et le 160 MHz annoncé à la certification Wi-Fi Alliance, et il est bridé à 80 MHz sans aucun réglage possible.

J’ai posté les mêmes mesures sur la Communauté Orange en demandant que le sujet soit transmis aux équipes techniques.

Mes questions ici :

Est-ce que d’autres abonnés avec ce répéteur observent aussi 80 MHz en 5 GHz, y compris raccordé en Ethernet ?
Quelqu’un a-t-il exploré les API du répéteur (il tournerait sous prplOS) et repéré un paramètre de largeur de bande qu’on pourrait modifier ?

Merci encore pour l’aide.

Ah ok je pensais que tu n'avais pas d'ipv6.

Pour tayga, si tu veux j'ai un script qui le relance automatiquement (dans mon cas j'utilise clatd qui fait appel à tayga mais ça revient au même). Ça surveille le ping en v4 ou une réponse http (dans le cas où le ping est bloqué, ce qui m'arrive de temps en temps chez bouygues selon le préfixe), ça fait des mois que ça tourne sans soucis.

Je l'ai aussi intégré dans un service systemd pour que ce soit plus pratique.

Sur l'optimisation, pour être le plus transparent possible c'est d'utiliser en priorité le DNS64, même si c'est souvent la loterie suivant l'application, j'ai parfois pas mal de trafic IPv4 et je ne sais pas trop comment forcer strictement l'ipv6 sauf si on demande une IPv4 en dur. Côté tayga, régler la MTU la plus grande possible (en gardant une marge de sécurité), avec Bouygues je la fixe à 1420 (en prenant 1440-1460 de MTU globale). J'évite 1500 car elle peut varier d'un préfixe à l'autre et après ça risque d'être complètement HS.

#!/bin/sh
IP1=8.8.8.8
IP2=80.67.167.77
IPV6_TEST=2001:bc8:610:f:7ec2:55ff:fea9:6d88 # ipv6.lafibre.info
IPV4_HTTP_TEST=195.154.246.97 # ipv4.lafibre.info
MAX_WAIT=60
INTERVAL=5

check_ipv6_icmp() {
    ping -6 -c 2 -W 3 $IPV6_TEST >/dev/null 2>&1
    return $?
}

check_ipv6_http() {
    curl -6 -s --head --connect-timeout 3 http://[${IPV6_TEST}] | grep -q "200"
    return $?
}

check_ipv4_http() {
    curl -4 -s --head --connect-timeout 3 "$IPV4_HTTP_TEST" | grep -q "200"
    return $?
}

wait_for_ipv6() {
    echo "Waiting for IPv6 connectivity..."
    elapsed=0
    while ! check_ipv6_icmp; do
        echo "ICMPv6 failed, trying HTTP fallback..."
        if check_ipv6_http; then
            echo "IPv6 HTTP reachable despite ICMP failure"
            return 0
        fi

        sleep $INTERVAL
        elapsed=$((elapsed + INTERVAL))
        if [ $elapsed -ge $MAX_WAIT ]; then
            echo "IPv6 toujours indisponible apres $MAX_WAIT secondes."
            return 1
        fi
    done
    echo "IPv6 available via ICMP"
    return 0
}

echo "Start ping"
while true; do
    sleep 10 # sleep 10 pour v2.1, 5 pour v1.6

#check_public_ipv4_change

    ping -W 5 -c 3 $IP1 >/dev/null &
    PID1=$!
    ping -W 5 -c 3 $IP2 >/dev/null &
    PID2=$!

    if wait $PID1; then
        echo >/dev/null
    elif wait $PID2; then
        echo >/dev/null
    else
        echo "All pings failed, checking IPv4 HTTP fallback..."

        if check_ipv4_http; then
            echo "IPv4 HTTP reachable, skipping clatd restart"
        elif wait_for_ipv6; then
            echo "Restarting clatd service"
            systemctl stop clatd.service
    sleep 0.5
            deprecated2=$(ip addr show dev ens18 | sed -n '/deprecated/s/.*inet6 \([^ ]*\) .*/\1/p')

for ip in $deprecated2; do
        # Supprimer l'adresse IPv6 deprecie
        ip -6 addr del $ip dev ens18
        echo "Deleted deprecated IP: $ip on interface: ens18"
    done
            sleep 4
            systemctl start clatd.service
            sleep 1
            systemctl start clatd.service
            echo "clatd restarted"
        else
            echo "Restart canceled: no IPv4 or IPv6 connectivity"
        fi
    fi
done


Je laisse vivien décider pour le coup

Je suis le seul que ça gonfle, ces sujets de vida18 sur des projets vibe-codé random, sans intérêt particulier, et sans lien non plus avec la thématique du forum ? Sans non plus aucune question ni avis personnel ni ouverture de discussion, juste une reprise verbatim d'autres sites ?

C'est sans doute une réaction exacerbée de ma part par une surexposition forcée à tout ce qui est IA, mais perso je n'en peux plus.