Pour information, nouvelle occurrence aujourd'hui à 16h01 (comme tous les jours au final…) je me suis posté devant la Freebox et elle n'affiche rien de spécial elle reste sur l'heure.

Bonjour @pablomg,

Est-ce que vous arrivez à pinguer les IP de votre réseau local depuis votre réseau local durant votre perte de connexion ? Oui

Est-ce que vous arrivez à pinguer 8.8.8.8 durant votre perte de connexion ? Non

29/06/2025 16:03:03 - Réponse de 8.8.8.8 : octets=32 temps=13 ms TTL=116
29/06/2025 16:03:04 - Réponse de 8.8.8.8 : octets=32 temps=14 ms TTL=116
29/06/2025 16:03:08 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:13 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:18 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:23 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:28 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:33 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:38 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:43 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:48 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:53 - Délai d'attente de la demande dépassé.
29/06/2025 16:03:58 - Délai d'attente de la demande dépassé.
29/06/2025 16:04:03 - Délai d'attente de la demande dépassé.
29/06/2025 16:04:08 - Délai d'attente de la demande dépassé.
29/06/2025 16:04:09 - Réponse de 8.8.8.8 : octets=32 temps=13 ms TTL=116
29/06/2025 16:04:10 - Réponse de 8.8.8.8 : octets=32 temps=13 ms TTL=116

Bonjour Thibaut,

J'arrive à joindre le réseau local sans soucis durant la coupure c'est uniquement l'accès à internet.

Je vais étudier votre piste malgré que je n'aie aucun appareil qui est censé se déclencher à ce moment-là. Est-ce que de votre côté, vous ne voyez pas un équipement qui essaye subitement d'accèdez à internet vers cette heure-là pour m'aider ? Je pourrais commencer par là et essayer de le débrancher. Il faut prendre en compte que je ne peux tester qu'un appareil par jour car le reste du temps je n'ai aucuns soucis.

Merci d'avance pour votre aide

Bonjour je reviens vers vous juste pour vous tenir au courant et vous dire que je n'ai toujours pas trouvé ce qui pourrait causer ça et j'ai de plus remarquer que le problème se décale dans le temps. Ces derniers temps ça a donc était 16h03 puis 16h04 … aujourd'hui 16h09

même problème

Bonjour,

Je rencontre exactement le même problème que celui décrit ici, tous les jours, sans exception.

Depuis plus de 20 jours, j'appelle quotidiennement le support Free, et à chaque fois, la même réponse m’est servie : “il n’y a aucun problème sur votre ligne”. Pourtant, une coupure franche de la connexion survient entre 15h45 et 16h30, avec un décalage d’environ une minute chaque jour. La Freebox reste synchronisée (l'heure continue de s’afficher), preuve que la ligne est stable et que le problème se situe ailleurs — probablement côté IP ou routage.

Pour objectiver les faits, un script de surveillance réseau tourne actuellement sur deux machines : l’une connectée par câble Ethernet (allumée en continu), l’autre en Wi-Fi. Ces machines envoient un ping toutes les 5 secondes vers google.com et 8.8.8.8 dans la plage horaire critique. Résultat : la coupure est systématiquement détectée. J’ai également tenté d’allumer le décodeur Freebox TV pendant la coupure : aucun flux, aucune réponse. Et bien sûr, aucune désynchronisation visible dans Freebox OS, le DHCP reste actif.

Un rapport détaillé a été transmis au service réclamation (CSV + PDF avec logs et captures horodatées). Il ne s’agit ni d’un problème local, ni de Wi-Fi, ni d’Ethernet, encore moins de désynchro : c’est une perte brute de paquets de 30 à 60 secondes, tous les jours. Et ce n’est pas “dans ma tête”, les logs sont formels.

Ce qui est incompréhensible, c’est que malgré ces éléments, aucun suivi sérieux n’est enclenché. Le support répète “on a testé la box” alors qu’en réalité, seul un test de ligne est effectué. C’est précisément ce que je conteste depuis le début.

Je vous demande donc de mutualiser les cas, d’ouvrir une vraie analyse côté réseau, et de faire remonter cette anomalie au-delà du support de niveau 1.

Un courrier est en cours de transmission au service réclamation. Si la situation n’évolue pas rapidement, je changerai d’opérateur et transmettrai le dossier à 60 Millions de Consommateurs. J’ai 15 ans d’expérience dans l’IT, me faire passer pour un amateur par des scripts de support mal formés, ça va un moment. Surtout quand on paie plus de 60 € par mois.

Marre d'entendre que c'est environemental ou quoi ! mon infra ne bouge pas depuis des moi et je me retrouve exactement dans le cas de figure de @tototo, une coupure franche exactement aux mêmes heures, même situation

Peut-être qu'un mtr indiquerait un équipement où ça coince ?
https://github.com/appstars-dev/WinMTR

C'est déja le cas !

Ah je ne suis donc pas le seul, ça me rassure un peu… De mon côté, je suis en télétravail à 100% et je subis des coupures tous les jours, souvent en pleine réunion.
C’est devenu tellement récurrent que j’en viens à angoisser chaque jour à l’approche de « l’heure fatidique » où la connexion lâche.
Franchement, ça devient difficile à gérer, j’espère vraiment qu’une solution va être trouvée rapidement…

Merci Thibaut, pour ma part j'ai aucun souci avec le support très aimable qui m'a redirigé ici…

J'attends votre retour bonne journée à vous

Quelle chance avec le support. Moi, ils m'ont demandé de consulter un informaticien car j'appelais tous les jours après la coupure ! Sinon pour rebondir sur ce que dit @Thibaut Freebox, pouvons nous être sur qu'un équipement externe soit défaillant puisqu'il n'y a aucune perte de syncro pendant la panne ? En effet, ne serait ce pas un incident lié plutôt à un check vers un service externe à du matériel. Par ailleurs, le décalage d'une minute en avançant dans les jours laisse présager que la box ferait appel à un service externe comme un serveur et que ce dernier ne serait pas synchronisé à un serveur de temps comme ntpdate par exemple, d'ou le décalage de la panne d'une minute chaque jours.Je me pose la question car le support effectue des check sur la ligne, hors si c'était un équipement en dehors de chez moi de type routeur par exemple, il y aurait forcément une perte de syncro mais la c'est une perte de packet, la box affiche l'heure et mes équipements restent connectés. Par ailleurs mon pc windows connecté en wifi affiche sur la connexion wifi qu'il y a internet, donc je peux en conclure que le dhcp fonctionne. Je vous avoue que je n'ai pas effectué de traceroute depuis mon serveur linux pendant la coupure. Par contre j'effectue des ping vers google.com et 8.8.8.8 entre 15h45 et 16h30 via une cron et un script bash. Voici un extrait du log d'aujourd'hui :

2025-07-10 16:18:10 - IP: OK - DNS: OK
2025-07-10 16:18:15 - IP: ❌ - DNS: ❌
2025-07-10 16:18:24 - IP: ❌ - DNS: ❌
2025-07-10 16:18:33 - IP: ❌ - DNS: ❌
2025-07-10 16:18:42 - IP: ❌ - DNS: ❌
2025-07-10 16:18:51 - IP: ❌ - DNS: ❌
2025-07-10 16:19:00 - IP: ❌ - DNS: ❌
2025-07-10 16:19:09 - IP: OK - DNS: OK

Comme on peut le voir j'ai eu la coupure à 16h18 et 15 secondes aujourd'hui ! Demain sera elle à 16h19 ?

Voici également un ticket lié à cet incident : 40396

Il est également possible de consulter la réponse de free obstiné à chercher quelque chose sur la ligne et qui n'a rien résolu depuis 1 mois mais qui en plus comme ils me l'ont dit par téléphone hier : "Nous en autre chose à faire que de recevoir vos appels quotidiens, nous vous conseillons de voir un informaticien" . . . ça tombe bien, c'est mon métier depuis plus de 15 ans. Déja qu'aux premières coupures, on m'a demandé de remettre les dns par défaut et de fermer les ports ouverts selon eux destiné aux jeux ^^ alors que la raison était simplement de passer sur cloudflare dns et pour les ports 80 et 443 d'ouvert, c'est pour mon serveur web… Bref, j'ai remis la box par défaut pour leur faire plaisir et je suis passé en IPv6 avec les dns en dur sur mon serveur (comme ça ils sont content). Par ailleurs, quand on y connais rien on ne dit pas des absurdités comme : "ah oui mais les dns peuvent perturber le réseau on a déja vu" ou "autoriser des ports servent à accélérer internet" …. Bref, c'est grave !

J'ajoute le lien vers leur réponse. Je sais d'avance qu'un informaticien ne fera pas le boulot de free n'ayant aucun accès backoffice de l'infra free ou du freebox os

https://assistance-1.free.fr/asy/14615565-921e35d4cbf5dcf1cedede69eb0a75c4d4161bc9.html

Bonjour,

Aujourd'hui petite nouveauté coupure de 10 minutes au lieu de la minute habituelle (15h48-15h58) avec également la perte du réseau Free Mobile (données et data) en supplément. Peut être lié à vos opérations pour trouver l'origine du problème ?

Bon weekend à tous

+ la coupure habituelle de 1min à 16h21

Bonjour,

Je rencontre le même problème mais cela ce produit peu après minuit, chaque jours pendant quelques minutes ….
Avec une Freebox pop

Bonjour @btx, c'est à dire ? Des coupure il y en a mais quand vous dite même problème, cela ne dit pas si il est de la même nature ! Dans notre cas, l'heure s'affiche, les équipements wifi sont connectés, le support free ne signalent aucun problème de ligne et d'ailleurs vérifiable car la box affiche l'heure et non l'étape 2, est ce votre cas ? La nature de notre coupure est purement un perte de packet, pas une désyncronisation de ligne et cette panne se produit vers 16h avec un décalage d'une minute chaque jour. Voici les logs relevés hier pendant la coupure :

2025-07-11 16:20:47 - IP: OK - DNS: OK
2025-07-11 16:20:52 - IP: ❌ - DNS: ❌
2025-07-11 16:21:01 - IP: ❌ - DNS: ❌
2025-07-11 16:21:10 - IP: ❌ - DNS: ❌
2025-07-11 16:21:20 - IP: ❌ - DNS: ❌
2025-07-11 16:21:29 - IP: ❌ - DNS: ❌
2025-07-11 16:21:38 - IP: ❌ - DNS: OK

Ces logs concernent uniquement cette coupure. Appart cet incident, hier, un autre c'est produit, cette fois ci concernant une désynchronisation fibre entre 15h48 à 15h58 excatement comme le dit @tototo

Bonjour,

Je rencontre le même problème depuis environ fin juin sauf que c'est aux alentours 1h00 du matin ( autour de 1h02-1h10-1h29 de jours en jours vers fin juin début juillet ) la box restait opérationnelle mais " signal non détecté " dans état FTTH et " connexion indisponible " dans l'onglet service dans Freebox OS .

Et ce soir même, rebelote mais à 00h49 et pendant plusieurs minutes, et au bout d'un moment box bloquée quelques minutes en étape 2 . J'ai remarqué qu'il y a pas mal de monde touché sur free dans ma ville au même moment et ainsi que dans d'autres régions depuis la même période que vous et moi ( autour de fin juin ).

L'assistance Freebox ne m'a rien dis de particulier excepté l'habituel " on va mettre votre ligne sous surveillance " et sans réponses par la suite même avec plusieurs appels et contact via WhatsApp . C'est usant .

Perso depuis la migration Freebox révolution > ultra et migration cuivre > fibre c'est un vrai cauchemar tout les jours depuis l'installation fin février, tv qui bug tout les jours à de nombreuses reprises ( sablier rouge ou erreur dash ), nombreuses coupures reseaux, streaming qui cafouille, je regrette la stabilité que j'avais que le cuivre malgré l'augmentation de débit certes agréable …

Bonjour @OGX70000 , ce n'est pas le même problème car pour le coup nous avons une coupure hors perte de signal dans l'état FTTH. Il faut faire un nouveau ticket

Bonjour,

Le soucis est toujours présent je ne sais pas s'il est encore utile de mentionner toutes les occurrences chaque jour 16h34 aujourd'hui.

N'hésitez pas si vous avez besoin de plus d'informations de ma part.

Cordialement,

Est-ce qu'il serait possible de faire les tests en IPv4 et en IPv6 pour orienter un peu le problème ? Le problème touche-t-il les deux familles ? En pinguant par exemple 2600::.

Et si cela touche IPv6, un traceroute vers 2600:: pendant le problème.

Bonjour, ce n'est pas vraiment le problème car une zone DNS résoud v' et v6 et la box donne une ipv4 et v6 donc si un des deux merde, on devrait quand même avoir des sites web qui s'affichent du fait que lors d'une navigation ton pc prendra la résolution la plus rapide. Maintenant si tu veux je pingue en ipv6 lors de mes tests.

Je ne sais pas si j'ai été clair mais en gros, si tu coupe ipv4, tu as encore la possibilité de naviguer sur des sites web et si tu coupe ipv6 aussi.

Ayant une ipv4 et une ipv6 si un des deux est en panne, tu as la résolution la plus rapide. Actuellement, j'ai les deux ipv4 et ipv6 et la résolution la plus rapide se fait en ipv6 (logique) :

root@yunohost:~# /bin/bash /opt/check_network
2025-07-18 11:42:35 - ──────────────────────────────────────────────────────────
2025-07-18 11:42:35 - DÉMARRAGE SURVEILLANCE – Fin prévue : 2025-07-18 17:00:00
2025-07-18 11:42:35 - Cibles IPv4=8.8.8.8 | IPv6=2001:4860:4860::8888 | DNS=google.com
2025-07-18 11:42:35 - Intervalle : 5s – Traceroute : 15 hops max
2025-07-18 11:42:35 - ──────────────────────────────────────────────────────────
2025-07-18 11:42:35 - IPv4 : OK (14.5 ms) | IPv6 : OK (14.4 ms) | DNS : OK (14.8 ms) (OK → 2a00:1450:4007:80b::200e)
2025-07-18 11:42:41 - IPv4 : OK (14.4 ms) | IPv6 : OK (14.5 ms) | DNS : OK (14.4 ms) (OK → 2a00:1450:4007:80b::200e)
2025-07-18 11:42:46 - IPv4 : OK (14.9 ms) | IPv6 : OK (14.8 ms) | DNS : OK (14.6 ms) (OK → 2a00:1450:4007:80b::200e)
2025-07-18 11:42:51 - IPv4 : OK (14.4 ms) | IPv6 : OK (14.6 ms) | DNS : OK (14.9 ms) (OK → 2a00:1450:4007:80b::200e)
2025-07-18 11:42:56 - IPv4 : OK (14.6 ms) | IPv6 : OK (14.4 ms) | DNS : OK (15.1 ms) (OK → 2a00:1450:4007:80b::200e)
2025-07-18 11:43:02 - IPv4 : OK (14.2 ms) | IPv6 : OK (14.4 ms) | DNS : OK (15.2 ms) (OK → 2a00:1450:4007:80b::200e)

Comme tu peux le voir, dès que je pingue google.com, le resolvdns sur 2a00:1450:4007:80b::200e est la réponse la plus rapide. Si ipv6 est en panne alors ipv4 sera retourné !

Eclate toi si tu veux :

#!/usr/bin/env bash
#

  GREEN=$'\e[32m'; RED=$'\e[31m'; RESET=$'\e[0m'

  GREEN=''; RED=''; RESET=''

  case $1 in
      OK*)         printf "%s%s%s" "$GREEN" "$1" "$RESET" ;;
      *)           printf "%s%s%s" "$RED"  "$1" "$RESET" ;;
  esac

  local header="[TRACE] --- traceroute -$1 $2 ---"
  log "$header" "$(colorize "$header")"
  traceroute -n -$1 -m "$TRACE_HOPS" "$2" 2>&1 | while IFS= read -r line; do
      log "[TRACE] $line" "[TRACE] $line"
  done
  local footer="[TRACE] --- traceroute end ---"
  log "$footer" "$footer"

  "DÉMARRAGE SURVEILLANCE – Fin prévue : $human_end"

  "Cibles IPv4=$TARGET_IPV4 | IPv6=$TARGET_IPV6 | DNS=$TARGET_HOST"

  "Intervalle : ${INTERVAL}s – Traceroute : ${TRACE_HOPS} hops max"

  # IPv4
  if out4=$(run_ping 4 "$TARGET_IPV4"); then
      rtt4=$(extract_rtt_ms <<<"$out4")
      ipv4_raw="OK (${rtt4} ms)"
  else
      ipv4_raw="FAIL"
      run_traceroute 4 "$TARGET_IPV4"
  fi

  # IPv6
  if out6=$(run_ping 6 "$TARGET_IPV6"); then
      rtt6=$(extract_rtt_ms <<<"$out6")
      ipv6_raw="OK (${rtt6} ms)"
  else
      ipv6_raw="FAIL"
      run_traceroute 6 "$TARGET_IPV6"
  fi

  # DNS
  dns_ip=$(getent ahosts "$TARGET_HOST" | awk 'NR==1{print $1}')
  if [[ -n "$dns_ip" ]]; then
      dns_resolve="OK → $dns_ip"
      if outdns=$(ping -n -c 1 -W 2 "$TARGET_HOST" 2>&1); then
          rtt_dns=$(extract_rtt_ms <<<"$outdns")
          dns_raw="OK (${rtt_dns} ms)"
      else
          dns_raw="PING_FAIL"
          run_traceroute 4 "$dns_ip"
      fi
  else
      dns_resolve="RESOLVE_FAIL"
      dns_raw="RESOLVE_FAIL"
  fi

  # Construction ligne
  plain="IPv4 : $ipv4_raw | IPv6 : $ipv6_raw | DNS : $dns_raw ($dns_resolve)"
  colored="IPv4 : $(colorize "$ipv4_raw") | IPv6 : $(colorize "$ipv6_raw") | DNS : $(colorize "$dns_raw") ($dns_resolve)"

  log "$plain" "$colored"
  sleep "$INTERVAL"

root@yunohost:~# /bin/bash /opt/check_network
2025-07-18 11:44:19 - ──────────────────────────────────────────────────────────
2025-07-18 11:44:19 - DÉMARRAGE SURVEILLANCE – Fin prévue : 2025-07-18 17:00:00
2025-07-18 11:44:19 - Cibles IPv4=8.8.8.8 | IPv6=2001:4860:4860::8888 | DNS=google.com
2025-07-18 11:44:19 - Intervalle : 5s – Traceroute : 15 hops max
2025-07-18 11:44:19 - ──────────────────────────────────────────────────────────
2025-07-18 11:44:19 - IPv4 : OK (14.5 ms) | IPv6 : OK (14.8 ms) | DNS : OK (14.3 ms) (OK → 2a00:1450:4007:80b::200e)
^C
root@yunohost:~# rm -Rf /var/lo
local/ lock/  log/   
root@yunohost:~# rm -Rf /var/log/c
check-free/    cron.log       cron.log.1     cron.log.2.gz  cron.log.3.gz  cron.log.4.gz  
root@yunohost:~# rm -Rf /var/log/check-free/
root@yunohost:~# rm -Rf /var/log/network_check/
root@yunohost:~# cat /opt/check_network
#!/usr/bin/env bash
# ============================================================
#  Surveillance IPv4 / IPv6 / DNS – arrêt à 17 h aujourd’hui
#  Logs : /var/log/check-free/YYYY-MM-DD.log
# ============================================================
set -euo pipefail
shopt -s huponexit

# ─── Paramètres ─────────────────────────────────────────────
TARGET_IPV4="8.8.8.8"
TARGET_IPV6="2001:4860:4860::8888"
TARGET_HOST="google.com"

INTERVAL=5        # s
END_TIME="17:00"  # heure butoir
TRACE_HOPS=15
LOG_DIR="/var/log/check-free"
mkdir -p "$LOG_DIR"
LOG_FILE="$LOG_DIR/$(date +'%Y-%m-%d').log"

# ─── Couleurs (ANSI) ───────────────────────────────────────
if [[ -t 1 ]]; then          # stdout = terminal ⇒ on colore
    GREEN=$'\e[32m'; RED=$'\e[31m'; RESET=$'\e[0m'
else                         # pas de couleur pour cron/log
    GREEN=''; RED=''; RESET=''
fi

# ─── Fonctions utilitaires ─────────────────────────────────
# log_plain   : vers fichier uniquement
# log_console : vers stdout avec couleurs
# log()       : appelle les deux
log_plain()   { printf '%s - %s\n' "$(date '+%F %T')" "$1" >>"$LOG_FILE"; }
log_console() { printf '%s - %s\n' "$(date '+%F %T')" "$2"; }
log()         { log_plain "$1"; log_console "$1" "$2"; }

colorize() {                      # $1 = statut brut
    case $1 in
        OK*)         printf "%s%s%s" "$GREEN" "$1" "$RESET" ;;
        *)           printf "%s%s%s" "$RED"  "$1" "$RESET" ;;
    esac
}

run_ping() { ping -n -${1} -c 1 -W 2 "$2" 2>&1; }
extract_rtt_ms() { awk -F'/' '/^rtt/ {printf "%.1f",$5}'; }

run_traceroute() {               # $1=4|6 $2=IP
    local header="[TRACE] --- traceroute -$1 $2 ---"
    log "$header" "$(colorize "$header")"
    traceroute -n -$1 -m "$TRACE_HOPS" "$2" 2>&1 | while IFS= read -r line; do
        log "[TRACE] $line" "[TRACE] $line"
    done
    local footer="[TRACE] --- traceroute end ---"
    log "$footer" "$footer"
}

# ─── Calcul heure de fin ───────────────────────────────────
today=$(date +%F)
end_epoch=$(date -d "$today $END_TIME" +%s)
(( $(date +%s) >= end_epoch )) && { log_plain "Heure $END_TIME dépassée." ; exit 0; }
human_end=$(date -d "@$end_epoch" '+%F %T')

# ─── En‑tête ───────────────────────────────────────────────
header_line="──────────────────────────────────────────────────────────"
log "$header_line" "$header_line"
log "DÉMARRAGE SURVEILLANCE – Fin prévue : $human_end" \
    "DÉMARRAGE SURVEILLANCE – Fin prévue : $human_end"
log "Cibles IPv4=$TARGET_IPV4 | IPv6=$TARGET_IPV6 | DNS=$TARGET_HOST" \
    "Cibles IPv4=$TARGET_IPV4 | IPv6=$TARGET_IPV6 | DNS=$TARGET_HOST"
log "Intervalle : ${INTERVAL}s – Traceroute : ${TRACE_HOPS} hops max" \
    "Intervalle : ${INTERVAL}s – Traceroute : ${TRACE_HOPS} hops max"
log "$header_line" "$header_line"

# ─── Boucle ────────────────────────────────────────────────
while (( $(date +%s) < end_epoch )); do
    # IPv4
    if out4=$(run_ping 4 "$TARGET_IPV4"); then
        rtt4=$(extract_rtt_ms <<<"$out4")
        ipv4_raw="OK (${rtt4} ms)"
    else
        ipv4_raw="FAIL"
        run_traceroute 4 "$TARGET_IPV4"
    fi

    # IPv6
    if out6=$(run_ping 6 "$TARGET_IPV6"); then
        rtt6=$(extract_rtt_ms <<<"$out6")
        ipv6_raw="OK (${rtt6} ms)"
    else
        ipv6_raw="FAIL"
        run_traceroute 6 "$TARGET_IPV6"
    fi

    # DNS
    dns_ip=$(getent ahosts "$TARGET_HOST" | awk 'NR==1{print $1}')
    if [[ -n "$dns_ip" ]]; then
        dns_resolve="OK → $dns_ip"
        if outdns=$(ping -n -c 1 -W 2 "$TARGET_HOST" 2>&1); then
            rtt_dns=$(extract_rtt_ms <<<"$outdns")
            dns_raw="OK (${rtt_dns} ms)"
        else
            dns_raw="PING_FAIL"
            run_traceroute 4 "$dns_ip"
        fi
    else
        dns_resolve="RESOLVE_FAIL"
        dns_raw="RESOLVE_FAIL"
    fi

    # Construction ligne
    plain="IPv4 : $ipv4_raw | IPv6 : $ipv6_raw | DNS : $dns_raw ($dns_resolve)"
    colored="IPv4 : $(colorize "$ipv4_raw") | IPv6 : $(colorize "$ipv6_raw") | DNS : $(colorize "$dns_raw") ($dns_resolve)"

    log "$plain" "$colored"
    sleep "$INTERVAL"
done

log "FIN : 17 h atteinte – Surveillance terminée" "FIN : 17 h atteinte – Surveillance terminée"
root@yunohost:~# 

cron : 00 16 * * * /opt/check_network

Bonjour @vbernat,

Je suis en IPv4 sur mon PC Fixe et en IPv6 sur mon iPhone et le soucis est global sur les deux au même moment.

Je le répète au cas où c'est vraiment que internet la syncro reste en place, le réseau local est accessible et le problème se décale d'environ une minute par jour mais il est bien là tous les jours.

Cordialement,

Dis et redis dans le ticket, mais bon . . .

Nouvelle coupure wifi et ethernet sur tous les périphériques ! ça ne sort pas du réseau local :

2025-07-18 16:39:20 - IPv4 : OK (14.3 ms) | IPv6 : OK (14.7 ms) | DNS : OK (14.8 ms) (OK → 2a00:1450:4007:81a::200e)
2025-07-18 16:39:27 - [TRACE] — traceroute -4 8.8.8.8 — 2025-07-18 16:39:27 - [TRACE] traceroute to 8.8.8.8 (8.8.8.8), 15 hops max, 60 byte packets
2025-07-18 16:39:32 - [TRACE] 1 192.168.1.254 0.700 ms 0.463 ms 0.424 ms
2025-07-18 16:39:32 - [TRACE] 2 * * *
2025-07-18 16:39:32 - [TRACE] 3 * * *
2025-07-18 16:39:32 - [TRACE] 4 * * *
2025-07-18 16:39:32 - [TRACE] 5 * * *
2025-07-18 16:39:32 - [TRACE] 6 * * *
2025-07-18 16:39:37 - [TRACE] 7 * * *
2025-07-18 16:39:37 - [TRACE] 8 * * *
2025-07-18 16:39:37 - [TRACE] 9 * * *
2025-07-18 16:39:37 - [TRACE] 10 * * *
2025-07-18 16:39:37 - [TRACE] 11 * * *
2025-07-18 16:39:42 - [TRACE] 12 * * *
2025-07-18 16:39:42 - [TRACE] 13 * * *
2025-07-18 16:39:42 - [TRACE] 14 * * *
2025-07-18 16:39:42 - [TRACE] 15 * * *
2025-07-18 16:39:42 - [TRACE] — traceroute end — 2025-07-18 16:39:44 - [TRACE] — traceroute -6 2001:4860:4860::8888 — 2025-07-18 16:39:44 - [TRACE] traceroute to 2001:4860:4860::8888 (2001:4860:4860::8888), 15 hops max, 80 byte packets
2025-07-18 16:39:44 - [TRACE] 1 2a01:e0a:a4a:3500::1 0.689 ms 0.725 ms 0.464 ms
2025-07-18 16:39:49 - [TRACE] 2 2a01:e05:a:f836:7e72::ffff 1.976 ms 1.728 ms 1.414 ms
2025-07-18 16:39:49 - [TRACE] 3 * * *
2025-07-18 16:39:49 - [TRACE] 4 * * *
2025-07-18 16:39:49 - [TRACE] 5 * * *
2025-07-18 16:39:49 - [TRACE] 6 * * *
2025-07-18 16:39:49 - [TRACE] 7 * * *
2025-07-18 16:39:54 - [TRACE] 8 * * *
2025-07-18 16:39:54 - [TRACE] 9 * * *
2025-07-18 16:39:54 - [TRACE] 10 * * *
2025-07-18 16:39:54 - [TRACE] 11 * * *
2025-07-18 16:39:54 - [TRACE] 12 * * *
2025-07-18 16:39:59 - [TRACE] 13 * * *
2025-07-18 16:39:59 - [TRACE] 14 * * *
2025-07-18 16:39:59 - [TRACE] 15 * * *
2025-07-18 16:39:59 - [TRACE] — traceroute end — 2025-07-18 16:40:01 - [TRACE] — traceroute -4 2a00:1450:4007:81a::200e — 2025-07-18 16:40:01 - [TRACE] 2a00:1450:4007:81a::200e: Address family for hostname not supported
2025-07-18 16:40:01 - [TRACE] Cannot handle "host" cmdline arg `2a00:1450:4007:81a::200e' on position 1 (argc 5)
root@yunohost:~#

Le Trace 2 en ipv6 donne l'impression qu'il arrive au NRO mais n'en sort pas.

En effet, 2a01:e05:a:f836:7e72::ffff n’est pas l’IP d’un NRO, mais celle d’un routeur d’agrégation Free (BNG/PE) situé après le NRO.

Ceci étant dit, en ipv4, je n'atteind quand même pas google

j'ai même mieux :

guillaume@PC:~$ curl -s https://ipinfo.io/2a01:e05:a:f836:7e72::ffff {

"ip": "2a01:e05:a:f836:7e72::ffff",
"city": "Paris",
"region": "Île-de-France",
"country": "FR",
"loc": "48.8534,2.3488",
"org": "AS12322 Free SAS",
"postal": "75000",
"timezone": "Europe/Paris",
"readme": "https://ipinfo.io/missingauth"

}guillaume@PC:~$

Même problème… J’ai un Smokeping qui confirme les coupures tous les jours vers ~16h34 pendant environ une minute. (L’heure de la coupure avance de quelques minutes chaque jour…)
J’ai tout transmis à @free_1337 en DM également.

Freebox Révolution Fibre ici.