Bonjour Romain, Pour compléter la réponse de Michel, un "ip route get 54.38.38.159" lancé sur rpi4 à la survenance du problème permettrait de détecter un éventuel problème de routage sur rpi4.
Cordialement, Thomas 7 sept. 2023 12:55:53 Romain <[email protected]>: > Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le > serveur chez OVH. > Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en > même temps, peut-être une correction de leur côté. > A suivre. > > Le jeu. 7 sept. 2023 à 12:37, Michel Verdier <[email protected]> a écrit : >> Le 7 septembre 2023 Romain a écrit : >> >>> Je n'en ai aucune idée, mais : >>> - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à >>> reproduire sur une IP Scaleway >>> - depuis une VM hébergée sur un petit NUC branché au même switch que le >>> RPI4, je ne reproduis pas le problème avec MTR >>> >>> J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et >>> déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage >>> complet. >> >> Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu >> fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur >> l'ip 54.38.38.159 (mail.borezo.info[http://mail.borezo.info]). Celui qui >> bloque aboutit sur l'ip >> 192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de >> routage chez toi. Ce que confirmerait ton test avec le nuc. >> Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ? >> Regarde tes tables de routage sur rpi4 avant et pendant le problème pour >> voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers >> lui-même au lieu de l'avoir vers ta box. >>
