Pertes de connexion et latence aléatoire



Afficher le premier message

92 commentaires

Niveau d'utilisateur 7
Badge +12

Hum ,  

des erreurs ou déconnexions on ne sait pas ...je ne vois pas grand chose sur ce screen vous avez redémarré votre modem ces derniers jours ? 

remettez les événements à zéro qq jours sans reboot pour voir si on voit qqch de spécial 

Attention, le lease DHCP c’est pour le réseau local (LAN)  , pas pour internet (WAN)  le bail wan c’est voo qui gère et le premier bail après une coupure du modem c’est 1 H puis il renouvelle en baux de 8 H 

Niveau d'utilisateur 2
Badge +2

Voila depuis une diziaine de jours, j’avais en effet effectué un reset des évènements pour clear toutes ces connexions admin (liées aux conversations Facebook de mon père avec le service VOO). Avant cela, impossible de savoir moi-même, l’historique étant flood par les connexions VOO.

La dernière fois que je l’ai redémarré c’est vendredi avant que l’opérateur VOO ne se connecte, cependant, je n’ai pas eu d’erreur entre le 5 et le 9 novembre (YOUHOUUU :thinking: ).

On est bien d’accord que le modem a été réinitialisé, reboot de nombreuses fois suite à ces interventions et divers paramétrages essayés à la demande des opérateurs VOO.
C’est après toutes ces connexions que j’ai moi-même effectués les changements.

Je peux d’ailleurs vous certifier que ce n’est pas ces récents réglages qui causent ces soucis car on les avait déjà il y a plusieurs mois avec d’autres réglages et d’autres modems, un autre coupleur.

La connexion n’a d’ailleurs jamais été aussi stable (ne me faites pas dire que je n’ai plus de soucis !! Pas du tout) que depuis que j’ai les réglages indiqués sur mon poste. 

Perso, en voyant votre dernier screen des wifi, je me mettrait soit sur le 4, soit sur le 9 en 20 Mhz pour essayer la stabilité … au détriment de la vitesse qui semble de toute manière instable.

En 2me choix, le 3 ou le 8, mais risque d’être moins stable.

Quand il y a tant de wifi autour, il faut essayer à taton pour trouver le meilleur compromis.

 

Mais bon avec quelque chose de plus puissant que le Technicolor c’est pas mal non plus.

 

Niveau d'utilisateur 7
Badge +12

Il y a eu un ou deux redémarrages  après ...peut-être y a une longue perte de signal ?
En tout cas si ce n’est pas vous, il semble avoir redémarré une voire 2 fois tout seul alors … « Time not established » cela correspond à un démarrage car il n’a pas encore l’heure réseau…

Donc. Historique modem signal et décos a vérifier officiellement...

Niveau d'utilisateur 2
Badge +2

@DDA merci mais déjà essayé, le canal 6 est vraiment le plus stable et le moins fréquenté. 
En effet, j’y ai été à taton et le canal 6 est au final un des canaux le moins utilisé (malgré ce screen) mais surtout, le moins variable (j’ai du mal à parler d’un canal stable avec ce modem) et ce, même lorsqu’il y a du monde en interférence comme ici.

 

@roylion15 eh bien, bizarrement, si. Regardez. 

Screen datant  du 10/11:

 

Screen datant du 11/11:

 

Comme on peut le remarquer, le Warning (6) DHCP WARNING daté au 10 à 16h43 est devenu un Critical (3) DHCP FAILED sans date à l’arrivée du Warning (6) DHCP WARNING du 11 à 17h24.

Diminuer votre bande à 20 Mhz fixe ?

Niveau d'utilisateur 2
Badge +2

@DDA les réglages sont mis dans le premier message, déjà fait également. :slight_frown:

@DDA les réglages sont mis dans le premier message, déjà fait également. :slight_frown:


Ben oui, en 40Mhz fixe, ou alors j’ai mal compris …

Je vous cite :

Quand il y a des perturbation, je vais abandonner la vitesse pour obtenir quelque chose de plus stable moins vite, en fixant à 40 Mhz, c’est la vitesse qui sera privilégiée :thinking:

 

Niveau d'utilisateur 2
Badge +2

@DDA Vous avez en effet mal compris, ce sont les paramètres du 5GHz là, d’ailleurs désactivé comme on peut le voir au canal courant vide. Ceux du 2.4 sont juste avant les paramètres de sécurité.

Soit: 

 

Oui, je l’avais vu et mal compris la suite du fait d’avoir désactivé le 5 Ghz … autant pour moi :disappointed:

Niveau d'utilisateur 2
Badge +2

Je viens d’aller refaire un tour dans le modem et je viens de voir ceci:

 

Hmmmm wtf ?
C’est à cause du changement du délai de bail DHCP sans avoir redémarré le modem ou ça provient de l’erreur DHCP ci-dessus ?

Je ne saurais pas dire depuis quand c’est comme ça.
Encore tout à l’heure lorsque j’ai créé le sujet, il n’y avait aucune IP statique.

Niveau d'utilisateur 7
Badge +12

Vous confondez dhcp wan et lan , les événements c’est le wan et le réglage dhcp de tout à l’heure c’est sur le lan pour vos appareils…

sûrement parce que vous avez fait le réglage à 2 jours alors il indique n’importe quoi car durée plus longue que dhcp anormale, un bug qui se soigne effectivement par un cool reboot du modem à mon avis 😀

Niveau d'utilisateur 2
Badge +2

sûrement parce que vous avez fait le réglage à 2 jours alors il indique n’importe quoi car durée plus longue que dhcp anormale, un bug qui se soigne effectivement par un cool reboot du modem à mon avis 😀

Je ne sais pas de trop, il est vrai que de ce coté la, je n’y connais pas grand chose.

J’ai essayé de reconnecter mon smartphone au WIFI vers 00h20.
Un bail lui a donc été attribué.

J’essaye la même chose 10min plus tard avec mon portable et pareil, il obtient le bail.

 

Je viens d’aller recheck et il n’y en avait plus aucun. Ils étaient repassés en IP statique (à cause de leur innactivité ?) sans date d’expiration.

 

Lorsque j’ai été sur mon smartphone et de nouveau réactivé (déco-reco) le wifi, celui-ci est réapparu dans la liste avec une nouvelle date d’expiration au lieu de *** Adresse IP Statique *** et remplaçant son ancien bail. Le Macbook est, lui aussi réapparu.

 

Tant que la ligne est correcte, je préfère ne pas redémarrer le modem actuellement.
Je verrais la situation demain et effectuerais le reboot avant de revenir vers vous.

Niveau d'utilisateur 7
Badge +12

😀

bien vite le routeur parce que si voulez trouver des bugs ou bizarreries dans l’interface , vous n’avez pas encore fini. 😂

 

 

Niveau d'utilisateur 2
Badge +2

Bonjour à tous,

En reparcourant mes screenshots, je me suis aperçu que les valeurs Tx avaient tendance à être assez différentes suivant le signal Rx des canaux descendants. 
Je ne sais pas si ça peut réellement avoir un impact sur la connexion dans un cas ou un autre.

Les différentes données dates entre le 06 et le 11/11.

 

Je ne dis pas que c’est un problème, je ne sais pas. Je constate et pose la question. :thumbsup:
Je veux vraiment que ça bouge cette fois.

J’attends donc l’avis d’un officiel sur l’ensemble de ce sujet.

 

@roylion15 si même ce n’est en effet que des bugs, c’est malgré tout dommage. Même les clients qui voudraient y comprendre quelque chose ne pourraient pas.
Depuis le temps que ce modem existe, c’est quand même dommage tous ces bugs. Un peu le même constat que pour la VOO.evasion au final. :cold_sweat:

Niveau d'utilisateur 7
Badge +12

Ce n’est pas un problème … si le RX monte, le TX a la tendance inverse , les variations de la température extérieure en sont la cause et c’est normal.

Une mise à jour prochaine devrait résoudre certains bugs gênants et améliorer la stabilité mais bon cela dépend du bon vouloir du fabricant Technicolor aussi et non de VOO uniquement. 

Niveau d'utilisateur 2
Badge +2

De nouveau, après une journée parfaite (vitesses supérieures aux valeurs annoncées).
Voila que, sans réelle raison, le wifi se voit baisser drastiquement de qualité.

Ceci a été fait par wifi, on peut également remarquer le test de pings très variable + le ping perdu:

 

Et un second effectué 10min plus tard, le signal a repris un peu malgré une baisse de vitesse sur la fin, comme dans les ¾ du temps lors de tests wifi actuellement chez moi:

 

Je n’ai pas regardé à l’instant T mais tous les canaux montants et descendants du modem sont dans les mêmes valeurs que dans les tableaux ci-dessus.

Le speedtest réalisé par RJ-45 est quant à lui un peu moins bon que normalement avec une courbe de montée moins franche et un débit maximum de 111Mbps. 

Les résultats étant 8ms de ping, 109.51Mbps en down et 6,87 en upload.

 

Et de nouveau, je reviens sur cette histoire de bruit:

Aujourd’hui, tous les signaux wifi ont un bruit stable.

Tous, sauf 2. Mon wifi (VOO-013256) + le wifi voisin (VOO-386550), le Devolo branché dans notre cuisine à quant à lui un bruit totalement stable.

Comment expliquer cette différence ? Y-a-t-il une crasse sur le réseau VOO vu l’exactitude entre les bruits émis sur les 2 wifi ?

(je n’ai affiché que les signaux concernés pour plus de clarté)

Niveau d'utilisateur 7
Badge +11

En tant normal le TX ne bouge pas avec les changements de température. 

Si le TX bouge fortement avec les changements de température ça veut dire qu'il y a un défaut dans la ligne. Quand je dis fortement c'est plus de 5 dB.

Les changements de température ici n'affecte pas votre signal car ce n'est que de 2 dB, aussi bien sur le RX que le TX. 

Niveau d'utilisateur 2
Badge +2

Merci@mikL pour la réponse. 

 

J’ai effectué plusieurs tests de pings en wifi et ils arrivent tous à peu près au même schéma..

MacBook-Pro-de-Florian-2:~ joasflo$ ping -c 50 -s 68 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 68 data bytes

76 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=40.815 ms

76 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=22.875 ms

76 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=33.961 ms

76 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=34.785 ms

76 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=27.659 ms

76 bytes from 8.8.8.8: icmp_seq=5 ttl=52 time=60.207 ms

76 bytes from 8.8.8.8: icmp_seq=6 ttl=52 time=113.321 ms

76 bytes from 8.8.8.8: icmp_seq=7 ttl=52 time=124.502 ms

76 bytes from 8.8.8.8: icmp_seq=8 ttl=52 time=78.400 ms

76 bytes from 8.8.8.8: icmp_seq=9 ttl=52 time=73.747 ms

76 bytes from 8.8.8.8: icmp_seq=10 ttl=52 time=164.459 ms

76 bytes from 8.8.8.8: icmp_seq=11 ttl=52 time=157.293 ms

76 bytes from 8.8.8.8: icmp_seq=12 ttl=52 time=153.442 ms

76 bytes from 8.8.8.8: icmp_seq=13 ttl=52 time=161.350 ms

76 bytes from 8.8.8.8: icmp_seq=14 ttl=52 time=106.662 ms

76 bytes from 8.8.8.8: icmp_seq=15 ttl=52 time=103.198 ms

76 bytes from 8.8.8.8: icmp_seq=16 ttl=52 time=114.125 ms

76 bytes from 8.8.8.8: icmp_seq=17 ttl=52 time=108.362 ms

76 bytes from 8.8.8.8: icmp_seq=18 ttl=52 time=127.916 ms

76 bytes from 8.8.8.8: icmp_seq=19 ttl=52 time=52.659 ms

76 bytes from 8.8.8.8: icmp_seq=20 ttl=52 time=95.704 ms

76 bytes from 8.8.8.8: icmp_seq=21 ttl=52 time=14.506 ms

76 bytes from 8.8.8.8: icmp_seq=22 ttl=52 time=14.202 ms

76 bytes from 8.8.8.8: icmp_seq=23 ttl=52 time=24.862 ms

76 bytes from 8.8.8.8: icmp_seq=24 ttl=52 time=42.081 ms

76 bytes from 8.8.8.8: icmp_seq=25 ttl=52 time=47.045 ms

76 bytes from 8.8.8.8: icmp_seq=26 ttl=52 time=51.885 ms

76 bytes from 8.8.8.8: icmp_seq=27 ttl=52 time=52.488 ms

76 bytes from 8.8.8.8: icmp_seq=28 ttl=52 time=14.566 ms

76 bytes from 8.8.8.8: icmp_seq=29 ttl=52 time=16.172 ms

76 bytes from 8.8.8.8: icmp_seq=30 ttl=52 time=40.020 ms

76 bytes from 8.8.8.8: icmp_seq=31 ttl=52 time=43.575 ms

76 bytes from 8.8.8.8: icmp_seq=32 ttl=52 time=21.201 ms

76 bytes from 8.8.8.8: icmp_seq=33 ttl=52 time=18.519 ms

76 bytes from 8.8.8.8: icmp_seq=34 ttl=52 time=15.129 ms

76 bytes from 8.8.8.8: icmp_seq=35 ttl=52 time=16.338 ms

76 bytes from 8.8.8.8: icmp_seq=36 ttl=52 time=20.596 ms

76 bytes from 8.8.8.8: icmp_seq=37 ttl=52 time=25.350 ms

76 bytes from 8.8.8.8: icmp_seq=38 ttl=52 time=184.010 ms

76 bytes from 8.8.8.8: icmp_seq=39 ttl=52 time=122.397 ms

76 bytes from 8.8.8.8: icmp_seq=40 ttl=52 time=171.553 ms

76 bytes from 8.8.8.8: icmp_seq=41 ttl=52 time=145.152 ms

76 bytes from 8.8.8.8: icmp_seq=42 ttl=52 time=14.847 ms

76 bytes from 8.8.8.8: icmp_seq=43 ttl=52 time=22.166 ms

76 bytes from 8.8.8.8: icmp_seq=44 ttl=52 time=34.120 ms

76 bytes from 8.8.8.8: icmp_seq=45 ttl=52 time=15.370 ms

76 bytes from 8.8.8.8: icmp_seq=46 ttl=52 time=16.047 ms

76 bytes from 8.8.8.8: icmp_seq=47 ttl=52 time=38.207 ms

76 bytes from 8.8.8.8: icmp_seq=48 ttl=52 time=18.945 ms

76 bytes from 8.8.8.8: icmp_seq=49 ttl=52 time=18.389 ms

 

--- 8.8.8.8 ping statistics ---

50 packets transmitted, 50 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 14.202/64.704/184.010/52.279 ms

 

 

MacBook-Pro-de-Florian-2:~ joasflo$ ping -c 50 -s 512 192.168.0.1

PING 192.168.0.1 (192.168.0.1): 512 data bytes

520 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=49.064 ms

520 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=84.219 ms

520 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=3.506 ms

520 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=4.702 ms

520 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=3.669 ms

520 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=19.960 ms

520 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=1.582 ms

520 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=1.540 ms

520 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=9.216 ms

520 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=2.978 ms

520 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=2.546 ms

520 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=17.845 ms

520 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=243.010 ms

520 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=123.838 ms

520 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=263.581 ms

520 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=132.685 ms

520 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=1.972 ms

520 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=9.579 ms

520 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=2.758 ms

520 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=10.404 ms

520 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=2.841 ms

520 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=10.486 ms

520 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=2.620 ms

520 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=2.719 ms

520 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=3.316 ms

520 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=15.077 ms

520 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=12.137 ms

520 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=40.598 ms

520 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=47.078 ms

520 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=73.343 ms

520 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=5.812 ms

520 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=1.776 ms

520 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=11.951 ms

520 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=6.865 ms

520 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=2.436 ms

520 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=127.738 ms

520 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=2.534 ms

520 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=10.412 ms

520 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=1.704 ms

520 bytes from 192.168.0.1: icmp_seq=39 ttl=64 time=1.651 ms

520 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=62.226 ms

520 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=117.024 ms

520 bytes from 192.168.0.1: icmp_seq=42 ttl=64 time=99.074 ms

520 bytes from 192.168.0.1: icmp_seq=43 ttl=64 time=6.217 ms

520 bytes from 192.168.0.1: icmp_seq=44 ttl=64 time=11.164 ms

520 bytes from 192.168.0.1: icmp_seq=45 ttl=64 time=12.424 ms

520 bytes from 192.168.0.1: icmp_seq=46 ttl=64 time=18.458 ms

520 bytes from 192.168.0.1: icmp_seq=47 ttl=64 time=1.689 ms

520 bytes from 192.168.0.1: icmp_seq=48 ttl=64 time=1.666 ms

520 bytes from 192.168.0.1: icmp_seq=49 ttl=64 time=1.792 ms

 

--- 192.168.0.1 ping statistics ---

50 packets transmitted, 50 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 1.540/34.070/263.581/58.051 ms

 

J’ai également effectué des tests de pings en RJ-45 venant de plusieurs connexions différentes.. On retrouve quelques pings plus élevés mais seulement légèrement visible (ici, lors du test directement sur le modem).  Les montées aléatoire de pings en RJ-45 (notamment sur le modem) s’amplifient lorsqu’il y a un mauvais débit.

Envoi d’une requête 'Ping'  8.8.8.8 avec 512 octets de données :
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=18 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=28 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=12 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=16 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=16 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=17 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=17 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=14 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=17 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=15 ms TTL=52
Réponse de 8.8.8.8 : octets=68 (envoyés 512) temps=13 ms TTL=52

Statistiques Ping pour 8.8.8.8:
    Paquets : envoyés = 50, reçus = 50, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 12ms, Maximum = 28ms, Moyenne = 14ms

 

C:\Users\Flo>ping -n 50 -l 512 192.168.0.1

Envoi d’une requête 'Ping'  192.168.0.1 avec 512 octets de données :
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=2 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=12 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=1 ms TTL=64

Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=6 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=2 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=3 ms TTL=64

Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps=2 ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64
Réponse de 192.168.0.1 : octets=512 temps<1ms TTL=64

Statistiques Ping pour 192.168.0.1:
    Paquets : envoyés = 50, reçus = 50, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 0ms, Maximum = 12ms, Moyenne = 0ms

 

Pourrions-nous en tirer une signification ?

Je fais attention d’effectuer ces tests en utilisant un minimum le réseau. 

Cependant, lors de l’utilisation de Netflix, de la TV numérique, de streamings (d’un minimum de bande passante en somme), aurais-je également une montée de ping si j’interroge le modem ou un serveur externe comme ici ? 
Qui, du coup, pourrait provoquer ce genre de temps de réponse et dans mon cas pourrait l’amplifier ?
Ou pas du tout ?

 

Depuis hier soir (tard), et plus souvent aujourd'hui, il m’arrive également d’avoir une “page inaccessible” lorsque je tente d’accéder au modem. Ca m’est arrivé plusieurs fois en 1h cette après-midi puis plus rien. Tant que j’y suis, je transmet l’info. :joy:

 

(mon sujet est en train de tourner un peu en un FAQ, j’en suis désolé, mais c’est peut-être ces questions qui me permettront d’être plus compréhensible avec les futurs techniciens qui viendront à domicile et les opérateurs si de nouveaux problèmes venaient à resurgir)

Niveau d'utilisateur 7
Badge +12

Hello

Je vous réponds brièvement encore 😀

Je ne comprends pas trop ce que vous tentez de démontrer avec vos tests ?  Le mauvais wifi ou un problème de connexion filaire ?

je vois pas trop ? 

Aussi pourquoi mettre ce paramètre pour tester avec des paquets plus importants de 512 octets dans vos Pings ?  64 c’est pas assez ? 

réponse OUI  si le réseau local est plus chargé par divers flux de téléchargements ou du streaming, vos tests de pings seront probablement plus élevés et donc faussés dans une certaine mesure…

Notez aussi si vous utilisez le P2P , c’est néfaste car le modem n’aime pas un trop grand nombre de connexions simultanées 

Bonsoir 

Niveau d'utilisateur 2
Badge +2

J’essaye de savoir si les problèmes que j’ai au niveau du wifi sont causés à cause du wifi ou simplement amplifiés par celui-ci.

Comme il a été dit, je me doute que le wifi (et encore plus celui d’un modem opé) aura toujours des faiblesses.

Cependant, je peux acheter un routeur aussi chers soit-il, si ma ligne n’est pas clean, ce ne sera pas lui qui résoudra le problème.

Je parle souvent de wifi car c’est la seule chose que je peux analyser, les autres données et relevées étant du ressort de l’opérateur. Et vu que celui-ci n’arrive (-ne veut) pas à solutionner le problème, j’essaye de le faire par moi-même (avec de mauvais instruments et surement pas assez de connaissances je l’avoue) en trouvant des explications là ou je pourrais en voir.

Je joue, regarde des streams et utilise Teamspeak assez régulièrement.

  • En jeu, ma latence peut-être assez variable, pas top pour les FPS (co en RJ-45)
  • J’ai des erreurs internet sur les streams qui indiquent une coupure venant de chez moi (co wifi et RJ-45)
  • J’ai souvent des pertes de paquets entrants/sortants sur TS en wifi mais cela arrive aussi en filaire
  • Ma connexion est globalement moins stable par mauvais temps (co wifi et RJ-45)
  • VOO.evasion et smart TV se déconnectent d’internet (à cause de ??). Nous devons alors soit redémarrer le modem soit se reconnecter au réseau en réindiquant le mdp. (co wifi)
  • Les smartphones et tablettes gardent le signal wifi mais perdent la connexion (en wifi donc). Nous devons alors se déconnecter et se reconnecter au réseau.

Je ne pense pas que tous ces problèmes viennent du modem.
Dans tous les cas, les 3 premiers points ne sont absolument pas à cause du wifi car les problèmes sont également présent en filaire. 

Après qlq constations, ca ne vient probablement pas de mon câblage intérieur vu les différentes connexions et le bon câblage mais je regarde encore pour en être certain et procède à différents tests.

Je tente donc de trouver, -pas de démontrer, le problème pour le solutionner.
Je cherches des réponses à mes questions.

Si toutes ces réponses se trouvent simplement dans l’achat d’un routeur neuf. Je trouve ca quand même vraiment moyen de la part de chez VOO.

A quoi ca sert d’offrir un débit élevé si c’est pour le brider derrière à cause d’un matériel pourrave ? Et je parle du modem en général, pas seulement du wifi.

Il ne supporte même pas le double routage ip !! On nous rabâche les oreilles avec l’ipV6 et les seuls concernés fournissent un modem qui n’est pas capable de fonctionner correctement avec celle-ci !! Surtout maintenant où l’ère du numérique est arrivée et installée et que tout tourne autour d’une connexion internet..

Il est impossible de voir ce qu’il se passe réellement au niveau des ports et des différents filtres. L’interface tout comme les rapports d’erreurs sont minimalisés au maximum, et comme dit plus haut, il est remplis de bugs. Même pas d’interface “avancé” avec juste quelques options et paramètres en plus. 

Il nous est donc presque impossible de faire quelque chose par soit même sans faire appel au service technique. Service technique toujours très sympa, mais pas toujours très au courant si je peux me permettre la métaphore.

Nous avons presque toujours eu des problèmes. Rien n’a jamais pu être correct en même temps.
Que ce soit le coupleur, le câblage externe, le matériel extérieur, le modem, le câblage interne effectué par les précédents techniciens, les VOO.evasion.. il y a toujours quelque chose d’autre qui ne va pas.

Ce qui rend à force et par conséquent, la ligne ainsi que les personnes l’utilisant instables.

Et vu qu’aucun officiel VOO ne pointe le bout de son nez, tant que je le pourrais, j’analyserais mon réseau de cette façon.

Je me rends bien compte que je pourrais vite glisser dans une psychose et vouloir “tout parfait”  mais je pense cependant pouvoir garder mes attentes dans les limites du raisonnable.
Et ce, même si cette fois, j’attends également plus de VOO.

 

Nous en avons simplement mare.

 

 

Biensur,

@roylion15, rien contre vous et je vous remercie encore de prendre le temps de me lire ainsi que de me répondre !!

Je me doute que mes interventions peuvent paraître “petites” mais ce forum est notre dernière solution.

Cependant, je dois bien dire que tout ceci m’intéresse énormément et les questions que je pose ici sont aussi des questions que je me pose, par curiosité et envie d’en savoir un peu plus la dedans. 

Pour vous répondre, je teste avec des pings de plus gros poids pour avoir un résultat ressemblant à un vrai échange de données.
L’utilisation de P2P n’est normalement que très limité chez moi. En tout cas, elle n’est pas régulière.
 

Niveau d'utilisateur 7

Bonjour,

 

Je n’ai pas les connaissances technique de Mikl ou de roylion (raison pour laquelle je n’interviens généralement pas sur ce type de sujet) mais je pense que vous vous compliquez la vie à vouloir voir/comprendre/démontrer un problème en utilisant le wifi.

 

Commencer par faire vos relevés (je ne sais pas s’ils sont pertinents ou pas, ce n’est pas mon domaine) uniquement sur un pc relié par câble directement au modem.

Le pc étant “sûr” (donc testé sur une autre connexion pour s’assurer qu’il est servicible à 100%) tout comme le câble (un câble neuf et de bonne qualité étant un atout).

On a déjà vu des faux contacts aléatoires sur des câbles rj45, mon épouse en avait fait les frais, ce n’est que parce que mon pc continuait à avoir internet alors que le sien se déconnectait parfois qu’on s’en est rendu compte.

Ne faites vos test qu’en filaire, vous éviterez déjà de cumuler des éventuels problèmes.

 

Votre phrase “On nous rabâche les oreilles avec l’ipV6 et les seuls concernés fournissent un modem qui n’est pas capable de fonctionner correctement avec celle-ci !!” me laisse penser que vous êtes mal informé.

Ou avez vous été pêcher que voo serait le seul concerné par l’IPV6 ? pensez vous que c’est voo qui a implémenté ça ?

L’IPV6 est une norme mondiale qui change le protocole d’adressage car l’IPV4 atteint doucement la saturation (c’est donc un système mondial pour avoir plus d’adresses internet).

Mais c’est vrai que parfois il est conseillé de désactiver la fonction IPV6 pour éliminer un souci potentiel, je ne pense toutefois pas que ce soit lié au modem voo en lui-même

Niveau d'utilisateur 7
Badge +12

Hum, oui ...

Je ne vois pas de souci en câblé , des résultats normaux malgré un “flood” de plus GROS paquets vers le DNS Google ou le modem … ce sont des valeurs “correctes”.

De toute façon c’est pas avec 50 pings que vous allez voir quelque chose de probant , il faut faire tourner un ping en continu pendant des heures ou jours qui pourrait vous montrer des défaillances ou encore installer un logiciel de monitoring comme PingPlotter ou autre et le laisser tourner sur une machine du réseau connectée directement par câble au modem pendant plusieurs jours …

Cela vous indiquerait des défaillances mais sans forcément en avoir la cause ...

Concernant les pings en wifi, vu que vous voulez tester comme cela et ce malgré cette fois, des PETITS paquets , on voit nettement des latences bien plus élevées et des instabilités, vous auriez pu aussi tester de la même façon avec des GROS paquets de 512 octets .. Donc ce serait plus significatif d’un premier problème lié au WIFI. 

Je peux lancer un monitoring de votre connexion depuis chez moi sur votre modem pour vous aider mais VOO peut le faire aussi et ils ont plus facile de voir directement les résultats en quelques heures / jours si la connexion au réseau VOO vers votre modem est en cause. 

A noter qu’ il peut y avoir un problème local chez vous notamment le wifi (ou autre souci matériel..) mais aussi un problème sur le réseau externe entre chez vous et le central sur lequel vous ne savez pas voir grand chose avec 50 pings lancés vers Google au “petit bonheur la chance” et que çà va déconner juste  à ce moment là …

A titre indicatif, j’ ai lancé en filaire un test de 2000 pings  sur un modem VOO avec des paquets de 512 octets, tout en travaillant sur ce PC et en téléchargeant quelques fichiers  … RAS …

ping -n 2000 -l 512 192.168.1.1

...

Statistiques Ping pour 192.168.1.1:
    Paquets : envoyés = 2000, reçus = 2000, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 0ms, Maximum = 2ms, Moyenne = 0ms

 

 

 

 

Niveau d'utilisateur 2
Badge +2

Commencer par faire vos relevés (je ne sais pas s’ils sont pertinents ou pas, ce n’est pas mon domaine) uniquement sur un pc relié par câble directement au modem.

Les tests de ping que je fais sont fait en câble et en wifi. 
J’ai déjà essayé des pings venant de différents ordinateurs et connexions RJ-45. Même de longueurs différentes.

Les résultats sont tous identiques sauf que par cable “les sauts” se voient moins. Je ne suis pas analyste, je racontes peut-être des bêtises. Peut-être que ces “sauts” n’ont pas réellement d’importance sur le signal, alors tant mieux. Je ne saurais pas le savoir en claquant des doigts et c’est pour ca que je pose la question ici.

 

Votre phrase “On nous rabâche les oreilles avec l’ipV6 et les seuls concernés fournissent un modem qui n’est pas capable de fonctionner correctement avec celle-ci !!” me laisse penser que vous êtes mal informé.

Ou avez vous été pêcher que voo serait le seul concerné par l’IPV6 ? pensez vous que c’est voo qui a implémenté ça ?

Je parle de VOO, seul concerné en tant que fournisseur de services Internet, en plus des services Web. Qui d’autre pour nous fournir (-utiliser) ces adresses ?

Ce n’est pas à moi de régler ceci ou de devoir choisir entre ipV4/ipV6. C’est à eux de nous les mettre à disposition. Se priver d’ipV6 (et donc d’accès à certains serveurs/sites) à cause du modem, c’est n’importe quoi aussi..

 

Mais c’est vrai que parfois il est conseillé de désactiver la fonction IPV6 pour éliminer un souci potentiel, je ne pense toutefois pas que ce soit lié au modem voo en lui-même

En faisant ceci, la moitié de nos soucis sont réglés alors le souci n’est pas potentiel.

 

il faut faire tourner un ping en continu pendant des heures ou jours qui pourrait vous montrer des défaillances ou encore installer un logiciel de monitoring comme PingPlotter

Merci, je cherchais un logiciel dans ce genre sans avoir trouvé.

J’ai déjà essayé des monitoring de plusieurs heures mais c’est pour lire les résultats au terminal que c’est dur après… 

Par contre j’étais tombé sur PRTG Network Monitor, je n’y ai rien compris.
Cependant, les seules alertes très régulières que j’avais c’etait des erreurs SSL. Y’aurait-il un souci du coté de chez VOO également par là comme j’ai pu le voir dans d’autres sujets du forum ?

 

Concernant les pings en wifi, vous auriez pu aussi tester de la même façon avec des GROS paquets de 512 octets .. 

Je peux lancer un monitoring de votre connexion depuis chez moi sur votre modem pour vous aider mais VOO peut le faire aussi et ils ont plus facile de voir directement les résultats en quelques heures / jours si la connexion au réseau VOO vers votre modem est en cause. 

Un grand merci de prendre cette peine.
Pour ce qui est des paquets → Google, je ne peux lancer des paquets plus gros, allez savoir pourquoi ?

 

Je n’attends que ca, que des officiels VOO prennent le relais. 

Croyez-moi, si je ne suis pas devenu technicien/analyste réseau, ce n’est pas par hasard. Mais là, j’ai pas trop le choix.

Niveau d'utilisateur 2
Badge +2

“POSTEZ SUR LE FORUM MONSIEUR, LES OFFICIELS VOUS REPONDRONT”

 

En attendant que les officiels VOO se réveillent, quelqu’un pourrait m’éclairer sur la signification des lignes rouges présentes ci-dessous ? Monitoring effectué par PingPlotter sur le serveur DNS VOO.

 

 

 

J’ai également encore eu des erreurs DHCP, sans avoir éteint/redémarré le TC.
Vraiment rien d’alarmant alors ? 

 

Commenter