@Geobass
Merci pour vos commentaires
Mais il y a une chose que vous navez pas compris dans les problèmes de coupures
c’est au niveau WAN, pas LAN
Donc faut arrêter de dire que cela provient de divers equippements connectés (en LAN)
c’est la gigabox qui a un problème..
Je me permets de recopier ce que le upc team avait reçu comme info :
---———————-
À votre demande, nous avons découvert ce qui suit jusqu’à présent :
- la DHCPREQUEST est faite par CMTS (boîte dans la rue)
- le modem confirme la demande
- après environ 1 minute, le modem fait une nouvelle demande
- cela se confirme à nouveau, mais le modem ne réagit alors plus
C’est là que nous devons découvrir pourquoi la deuxième demande est répétée et pourquoi elle n’arrive pas.
Member of @Upc_Team
---———————-
Le model ne réagit plus .. et plus rien n’est routé
CQFD
Et comme cela arrive à plusieurs personnes avec exactement les même symptomes et surtout à des endroits très différents .. Faut arrêter de se cacher “derrière” les appareils des utilisateurs
Je peux reproduire ces prob de coupures tous les jours, même avec un simple et uniquement appareil connecté
dernière coupure 18:23
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=28 ttl=54 time=9.50 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=29 ttl=54 time=11.8 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=30 ttl=54 time=12.9 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=31 ttl=54 time=15.4 ms
Problème Commence
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=33 ttl=54 time=10.6 ms
Coupure …
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=44 ttl=54 time=14.3 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=45 ttl=54 time=11.2 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=46 ttl=54 time=12.7 ms
La gigabox répond plus …
Elle revient à la vie.
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=60 ttl=54 time=14.6 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=61 ttl=54 time=10.7 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=62 ttl=54 time=11.0 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=63 ttl=54 time=9.51 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=64 ttl=54 time=11.7 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=65 ttl=54 time=9.87 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=66 ttl=54 time=11.4 ms
64 bytes from zrh04s14-in-f4.1e100.net (172.217.168.36): icmp_seq=67 ttl=54 time=10.9 ms
C’est exactement ce que le UPC Team a publié comme l’identification du problème
sauf que … au niveau support, ils n’assument pas ce qu’ils ont publié en interne ..
Si un appareil quelconque d’un utilisateur pouvait influer sur le DHCPrelease du côté WAN ce serait vraiment grave . donc faut arrêter.. de raconter n’importe quoi. Et pourquoi on nous propose un downgarde si il n’y avait pas de problème !!
J’en ai marre de payer pour un système qui ne fonctionne pas.