Discussion de forum
Connexion Port Ethernet câble très lente depuis version 4.4 de Hélix
Bonjour, J'ai découvert que depuis EXACTEMENT le moment où ma borne Hélix a été mise à jour de la version 4.2 à 4.4 (Software Image Name:CGM4140COM_4.4p6s1_PROD_sey en se connectant à la page Adm...
Bon je viens de faire une trace sur le port ethernet de la borne helix, je unplug ensuite replug, je vois quelque chose de très particulier, le laptop envoie des dhcp mais aucune réponse de la borne pendant comme vous avez vu autour de 30sec, autour de la 30ieme seconde je vois la borne répond au dhcp.
J'ai fais plusieurs tests+traces pour me convaincre, la même chose toutes les fois.
Donc c'est un bug de la borne.
J'ai une petite idée du bug, je vois des packets STP (bridge protocol) venant de la borne, et leur délai pour forwarder est de 15sec, en petit recap le STP est utilisé pour éviter des loop dans les switch ethernet.
Voici la cause de votre 30sec: (cherche "stp forward delay" dans google).
The Forward Delay timer defines the time that is spent in Listening or Learning state. The default Forward Delay value is 15 seconds. This means that the port stays in Listening state for 15 seconds and then stays in Learning state for another 15 seconds before transitioning to the Forwarding state.
Vu que vos machines ne sont pas les switch ethernet, c'est donc inutile que Helix fait le STP sur leur port ethernet, pour fixer le problème, videotron devrait avoir une config qui permet de mettre ON ou OFF le STP, mais bonne chance pour votre fix car Videotron gosse pas dans le firmware de Helix qui vient de Comcast et que c'est Technicolor qui fait le vrai travail 8-)
Comme work-around poche, je vous suggère de mettre vos devices wire sur un routeur qui branche sur la borne helix, ça masque le problème.
Joyeux Noel à tous.
Alors j'ai fait le test avec un vieux Linksys et ça prend 3sec à établir la connexion!!
Donc les math ne mentent pas : le STP (dont HMatrix a mentionné) cause un double délai de 15sec, allée et retour, donc 15+15+3 dans mon livre à moi ça fait 33sec. Ce qui est exactement le délai total que ça me prend à chaque fois (quand ça connecte) lorsque je suis pluggé direct dans la borne.
Bravo les gars pour toutes ces infos, vous êtes imbattables!
Alors comme mon vieux Linksys est 13 fois plus lent que ma connexion Vidéotron normale, j'ai dû m'acheter un switch. Au final je vais pe ben la conserver, mais au moins ma connexion sera rapide et mes problèmes réglés, peu importe ce que Comcast fera...
Salut FrancisL ,
Bonne année à toi et la gang sur ce forum, j'ai eu du fun à regarder ton problème. Je travaille 26+ années en réseau depuis les années 90's 8-) J'ai encore le feu sacré/le fun dans ce domain, parcontre ça me fait peur quand tu dis "le STP de HMatrix cause un double délai" 8-))
En fait le fixe est assez simple pour corriger le problème, message pour Videotron->Comcast->Technicolor, ou bien disabler le STP, ou bien baisser la valeur de "Forward Delay" à une valeur plus petite, au lieu de 15 utilise 1 par exemple ou 0, vu que le réseau de Helix est un réseau maison, pas trop critique de baisser le Forward Delay à une valeur très courte.
J'ai lu dans ce thread que sur Windows ça semble mieux aller que Linux, c'est facile à expliquer, le dhcp client fait des requests, sur linux il y a un délai pour envoyer le prochain request tout comme Windows, le délai double quand le server répond pas, j'ai pas fait de trace avec mon laptop linux mais je pense que les délais sont peut-être trop conservateur avant le prochain envoie du dhcp-request.
Pour ceux qui sont intéressés, je peux vous partager la trace wireshark que j'ai fait avec Win10.
Sur mon routeur ASUS AC68P je roule merlin-wrt firmware, c'est très simple de faire ce que je suggère en haut, soit disable le STP et changer le forward delay, tous les routeurs wifi sont basés sur linux, avec la command brctl on peut configurer tout ça sur Helix, "on" excluant la personne qui parle.
admin@RT-AC68P-BC28:/tmp/home/root# brctl showstp br0
br0
bridge id 8000.ac9e179dbc28
designated root 8000.ac9e179dbc28
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 0.00 bridge forward delay 0.00
ageing time 300.00
hello timer 1.78 tcn timer 0.00
topology change timer 0.00 gc timer 88.82
flags
Usage: brctl [commands]
commands:
addbr <bridge> add bridge
delbr <bridge> delete bridge
addif <bridge> <device> add interface to bridge
delif <bridge> <device> delete interface from bridge
setageing <bridge> <time> set ageing time
setbridgeprio <bridge> <prio> set bridge priority
setfd <bridge> <time> set bridge forward delay
HMatrix, j'ai corrigé le bout qui te faisait peur. 🙂 J'avoue que c'était pas écrit comme je le pensais.
Si Linux est plus slow dans son délai avant le prochain DHCP request, y doit probablement y avoir une raison. Ceci dit c au niveau du routeur que ça doit se corriger, n'est-ce pas. Mon vieux "Linksys fini" roule avec DD-WRT et j'ai vu l'option STP ENABLE/DISABLE en radio buttons... me semble c pas compliqué pour Comcast non plus. Mais pe sont-ils à faire de fréquents upgrades pour améliorer la borne et qu'ils vont y arriver un jour malgré la qualité questionnable de leurs tests de régression sur une fonctionalité qui était top notch depuis tjrs avant.
J'ai vu récemment que maintenant on peut changer les premiers digits de notre gateway IP, alors que ce printemps, et pe même cet été, on était forcé de débuter par 10, donc 10.x.x.x. Maintenant on peut mettre 142.1.1.1 si on veut. Alors ça bouge... mais parfois y a des impacts. 🙂
Bien hâte de voir comment ma nouvelle switch va rouler... en attendant Vidéotron/Comcast. Ou pe pas, si je décide de rester avec tout le temps.
Je vais tenter de me (re)mettre à faire du traçage pour le fun de voir la différence entre Linux et Windows, ça m'intrigue tout ça et je veux voir toute cette patante qui m'a causé autant de problèmes. 🙂
FrancisL, j'ai le sens de l'humour, pas une reproche en ta direction 8-) je faisais une farce, de toute façon j'y suis habitué, dans toutes les cie que j'ai travaillé quand le réseau plante, je suis le suspect no.1, le plus souvent les gars IT ont mal configuré leur patente et c'est plus facile de blâmer un dévelopeur, comme tu vois dans dévelopeur il y a le mot "peur".
Si tu as des traces dhcp sur linux ça serait cool de me partager vu que tu te portes volontaire.
PS: Utilise pas 142.1.1.1 comme adresse IP interne, vu que 142.x c'est une adresse publique, utilise plus le 10.x ou bien 172.16.x ou bien 192.168.x
Bonne chasse.
