Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème avec le wifi, particulièrement le soir.

billou

Salut, si j'en viens à demander un coup de main ici, c'est que je suis à cours d'idées, j'ai un routeur WNR3500Lv2 dont je suis pleinement satisfait, ce dernier dispose de 128Mo de nand flash, et 128Mo de ram, ce qui est bien mieux que la plupart des routeurs sur le marché pour y installer des firmwares alternatifs et faire tourner divers services. (D'ailleurs ce dernier est prévu pour par Netgear, le site MyOpenRouter est là pour ça.)

Côté matériel, on retrouve un SoC Broadcom BCM4718A et un Switch Gigabit Broadcom BCM53115s 4 ports, plus un port Wan, et la prise en charge du Wifi B/G/N sur les bandes 20 et 40Mhz, le tout équipé d'un port USB OTG.

Voilà le problème, depuis près de deux semaines, avec le firmware original, tout comme avec DD-WRT, et Tomato, les débits sont minables en Wifi et il y a de gros lags, sans compter que l'on a une meilleure réception de la freebox du voisin que notre propre routeur wifi... (d'ailleurs, le routeur sous firmware tomato indique un total de près de 17 points d'accès Wifi autour de chez moi, tous sur les canaux 6 & 11, et inférieurs à 5, du coup j'ai essayé les canaux 5, 7, 8, 9, 10, sans changements...)

J'ai pu tester 3 PC différents, et partager la connexion wifi de smartphones pour éviter d'utiliser le jeu de puces intégrées aux laptops, et le problème reste similaire, la connexion s'obtient souvent en 1Mbp sauf si on force les 54Mbps sur le routeur, et la commande ping renvoie que beaucoup de paquets sont perdus quand on ping le serveur/Nas ou le routeur, de 2 à 6% en journée, et jusqu'à 30% le soir, le ping variant entre 0.8ms et 30ms en journée, et jusqu'à 250ms en soirée, voir plus.

À noter que par câble réseau en gigabit, il n'y a aucun problème, aucune perte, et les débits ne posent pas le moindre souci.

Du côté des réglages du firmware du routeur, j'ai tout essayé, il y a eu un mieux quand j'ai activé les options "Frame Bust" et Interference Mitigation en y activant "Wlan Auto", j'ai également activé l'option Bluetooth Coexistence, depuis lors les machines se connectent à des vitesses comprises entre 12 et 225Mbps, mais plus on monte, moins les débits sont bons, et les pertes de paquets restent équivalentes, quoi qu'il arrive.

Voici un test avec iwconfig ce matin :

billou@Billou-laptop:~$ iwconfig 
lo        no wireless extensions.

wlan0     IEEE 802.11abg  ESSID:"Colocation_Vanilla"  
          Mode:Managed  Frequency:2.432 GHz  Access Point: 74:44:01:36:D1:EA   
          Bit Rate=54 Mb/s   Tx-Power=15 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=58/70  Signal level=-52 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:41   Missed beacon:0

Voici un ping vers l'adresse locale du routeur lorsqu'il n'y a pas d'activité sur le réseau, ce matin, pas de pertes de paquets :

$ ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=1 ttl=64 time=0.997 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=64 time=2.19 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=64 time=0.952 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=64 time=0.756 ms
64 bytes from 192.168.0.100: icmp_req=5 ttl=64 time=0.869 ms
64 bytes from 192.168.0.100: icmp_req=6 ttl=64 time=2.21 ms
64 bytes from 192.168.0.100: icmp_req=7 ttl=64 time=1.34 ms
64 bytes from 192.168.0.100: icmp_req=8 ttl=64 time=0.833 ms
64 bytes from 192.168.0.100: icmp_req=9 ttl=64 time=4.60 ms
64 bytes from 192.168.0.100: icmp_req=10 ttl=64 time=0.845 ms
64 bytes from 192.168.0.100: icmp_req=11 ttl=64 time=2.92 ms
64 bytes from 192.168.0.100: icmp_req=12 ttl=64 time=0.913 ms
64 bytes from 192.168.0.100: icmp_req=13 ttl=64 time=1.03 ms
64 bytes from 192.168.0.100: icmp_req=14 ttl=64 time=1.13 ms
64 bytes from 192.168.0.100: icmp_req=15 ttl=64 time=1.82 ms
64 bytes from 192.168.0.100: icmp_req=16 ttl=64 time=0.989 ms
64 bytes from 192.168.0.100: icmp_req=17 ttl=64 time=1.11 ms
64 bytes from 192.168.0.100: icmp_req=18 ttl=64 time=6.19 ms
64 bytes from 192.168.0.100: icmp_req=19 ttl=64 time=1.04 ms
64 bytes from 192.168.0.100: icmp_req=20 ttl=64 time=1.07 ms
64 bytes from 192.168.0.100: icmp_req=21 ttl=64 time=0.850 ms
64 bytes from 192.168.0.100: icmp_req=22 ttl=64 time=0.929 ms
64 bytes from 192.168.0.100: icmp_req=23 ttl=64 time=0.992 ms
64 bytes from 192.168.0.100: icmp_req=24 ttl=64 time=1.03 ms
64 bytes from 192.168.0.100: icmp_req=25 ttl=64 time=0.767 ms
64 bytes from 192.168.0.100: icmp_req=26 ttl=64 time=1.04 ms
64 bytes from 192.168.0.100: icmp_req=27 ttl=64 time=1.15 ms
64 bytes from 192.168.0.100: icmp_req=28 ttl=64 time=1.22 ms
64 bytes from 192.168.0.100: icmp_req=29 ttl=64 time=0.663 ms
64 bytes from 192.168.0.100: icmp_req=30 ttl=64 time=0.848 ms
64 bytes from 192.168.0.100: icmp_req=31 ttl=64 time=0.705 ms
64 bytes from 192.168.0.100: icmp_req=32 ttl=64 time=0.869 ms
64 bytes from 192.168.0.100: icmp_req=33 ttl=64 time=0.822 ms
64 bytes from 192.168.0.100: icmp_req=34 ttl=64 time=0.826 ms
64 bytes from 192.168.0.100: icmp_req=35 ttl=64 time=1.43 ms
64 bytes from 192.168.0.100: icmp_req=36 ttl=64 time=0.900 ms
64 bytes from 192.168.0.100: icmp_req=37 ttl=64 time=3.01 ms
64 bytes from 192.168.0.100: icmp_req=38 ttl=64 time=0.996 ms
64 bytes from 192.168.0.100: icmp_req=39 ttl=64 time=4.05 ms
64 bytes from 192.168.0.100: icmp_req=40 ttl=64 time=0.672 ms
64 bytes from 192.168.0.100: icmp_req=41 ttl=64 time=26.2 ms
64 bytes from 192.168.0.100: icmp_req=42 ttl=64 time=75.8 ms
64 bytes from 192.168.0.100: icmp_req=43 ttl=64 time=3.18 ms
64 bytes from 192.168.0.100: icmp_req=44 ttl=64 time=5.31 ms
64 bytes from 192.168.0.100: icmp_req=45 ttl=64 time=2.21 ms
64 bytes from 192.168.0.100: icmp_req=46 ttl=64 time=26.1 ms
64 bytes from 192.168.0.100: icmp_req=47 ttl=64 time=1.46 ms
64 bytes from 192.168.0.100: icmp_req=48 ttl=64 time=1.31 ms
64 bytes from 192.168.0.100: icmp_req=49 ttl=64 time=1.32 ms
64 bytes from 192.168.0.100: icmp_req=50 ttl=64 time=0.892 ms
64 bytes from 192.168.0.100: icmp_req=51 ttl=64 time=0.914 ms
64 bytes from 192.168.0.100: icmp_req=52 ttl=64 time=0.859 ms
64 bytes from 192.168.0.100: icmp_req=53 ttl=64 time=1.08 ms
64 bytes from 192.168.0.100: icmp_req=54 ttl=64 time=2.95 ms
64 bytes from 192.168.0.100: icmp_req=55 ttl=64 time=0.885 ms
64 bytes from 192.168.0.100: icmp_req=56 ttl=64 time=0.864 ms
64 bytes from 192.168.0.100: icmp_req=57 ttl=64 time=0.907 ms
64 bytes from 192.168.0.100: icmp_req=58 ttl=64 time=1.08 ms
64 bytes from 192.168.0.100: icmp_req=59 ttl=64 time=1.05 ms
64 bytes from 192.168.0.100: icmp_req=60 ttl=64 time=0.869 ms
64 bytes from 192.168.0.100: icmp_req=61 ttl=64 time=1.65 ms
^C
--- 192.168.0.100 ping statistics ---
61 packets transmitted, 61 received, 0% packet loss, time 60049ms
rtt min/avg/max/mdev = 0.663/3.520/75.882/10.386 ms

Et voilà ce qu'il se passe lorsqu'on exige un débit soutenu, ici l'exemple tient d'un film 1080P mis en cache par Mplayer via un partage réseau basé sur la techno NFS, les moments ou le ping monte à plus de 200ms se situe au moment ou Mplayer charge le film en cache, j'observe à ce moment là un débit réel d'environ 2,3 / 2,8 Mo/s via le wifi.
Ici encore, tôt le matin, pas de pertes de paquets, le soir c'est juste intenable... Des coupures tout le temps, un débit minable, des pertes de paquets, pas question de charger ce genre de vidéos depuis le serveur NFS.

ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=1 ttl=64 time=1.02 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=64 time=1.21 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=64 time=0.830 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=64 time=1.15 ms
64 bytes from 192.168.0.100: icmp_req=5 ttl=64 time=0.894 ms
64 bytes from 192.168.0.100: icmp_req=6 ttl=64 time=1.32 ms
64 bytes from 192.168.0.100: icmp_req=7 ttl=64 time=1.02 ms
64 bytes from 192.168.0.100: icmp_req=8 ttl=64 time=0.821 ms
64 bytes from 192.168.0.100: icmp_req=9 ttl=64 time=0.978 ms
64 bytes from 192.168.0.100: icmp_req=10 ttl=64 time=1.82 ms
64 bytes from 192.168.0.100: icmp_req=11 ttl=64 time=0.749 ms
64 bytes from 192.168.0.100: icmp_req=12 ttl=64 time=0.932 ms
64 bytes from 192.168.0.100: icmp_req=13 ttl=64 time=1.27 ms
64 bytes from 192.168.0.100: icmp_req=14 ttl=64 time=0.854 ms
64 bytes from 192.168.0.100: icmp_req=15 ttl=64 time=0.787 ms
64 bytes from 192.168.0.100: icmp_req=16 ttl=64 time=296 ms
64 bytes from 192.168.0.100: icmp_req=17 ttl=64 time=294 ms
64 bytes from 192.168.0.100: icmp_req=18 ttl=64 time=297 ms
64 bytes from 192.168.0.100: icmp_req=19 ttl=64 time=302 ms
64 bytes from 192.168.0.100: icmp_req=20 ttl=64 time=255 ms
64 bytes from 192.168.0.100: icmp_req=21 ttl=64 time=23.0 ms
64 bytes from 192.168.0.100: icmp_req=22 ttl=64 time=1.20 ms
64 bytes from 192.168.0.100: icmp_req=23 ttl=64 time=0.955 ms
64 bytes from 192.168.0.100: icmp_req=24 ttl=64 time=0.766 ms
64 bytes from 192.168.0.100: icmp_req=25 ttl=64 time=0.776 ms
64 bytes from 192.168.0.100: icmp_req=26 ttl=64 time=2.93 ms
64 bytes from 192.168.0.100: icmp_req=27 ttl=64 time=0.932 ms
64 bytes from 192.168.0.100: icmp_req=28 ttl=64 time=0.954 ms
64 bytes from 192.168.0.100: icmp_req=29 ttl=64 time=0.919 ms
64 bytes from 192.168.0.100: icmp_req=30 ttl=64 time=1.07 ms
64 bytes from 192.168.0.100: icmp_req=31 ttl=64 time=1.14 ms
64 bytes from 192.168.0.100: icmp_req=32 ttl=64 time=2.88 ms
64 bytes from 192.168.0.100: icmp_req=33 ttl=64 time=1.09 ms
64 bytes from 192.168.0.100: icmp_req=34 ttl=64 time=301 ms
64 bytes from 192.168.0.100: icmp_req=35 ttl=64 time=292 ms
64 bytes from 192.168.0.100: icmp_req=36 ttl=64 time=300 ms
64 bytes from 192.168.0.100: icmp_req=37 ttl=64 time=299 ms
64 bytes from 192.168.0.100: icmp_req=38 ttl=64 time=295 ms
64 bytes from 192.168.0.100: icmp_req=39 ttl=64 time=119 ms
64 bytes from 192.168.0.100: icmp_req=40 ttl=64 time=0.741 ms
64 bytes from 192.168.0.100: icmp_req=41 ttl=64 time=0.844 ms
64 bytes from 192.168.0.100: icmp_req=42 ttl=64 time=0.949 ms
64 bytes from 192.168.0.100: icmp_req=43 ttl=64 time=1.28 ms
64 bytes from 192.168.0.100: icmp_req=44 ttl=64 time=0.958 ms
^C
--- 192.168.0.100 ping statistics ---
44 packets transmitted, 44 received, 0% packet loss, time 43022ms
rtt min/avg/max/mdev = 0.741/70.800/302.677/122.315 ms

Quelqu'un aurait il une idée ?

Henry de Monfreid

Salut.

J'ai parfois résolu des problèmes de débit réel en baissant le débit théorique du routeur, en désactivant le WIF N, par exemple.

Tu peux aussi, baisser la puissance d'émission du routeur, parfois, ça peut aider. (hurler dans les oreilles de quelqu'un ne le fait pas entendre mieux) 😉 )

As-tu changé la clé ? Un petit malin te pompe peut-être la bande passante.

Un voisin vient peut-ếtre d'installer un routeur pas loin du tien, dans ce cas bouge le tien.

renaud07

S.O.D. a écritJ'ai parfois résolu des problèmes de débit réel en baissant le débit théorique du routeur, en désactivant le WIF N, par exemple.

+1 Sur mon AP TP-link, si je le laisse en mode N j'ai un débit de 1,8mo/s max alors que si je force en G j'ai 2,3mo/s...

Ungars

Bonjour,
En changeant le canal de ton wifi ? J' ai eu ce problème récemment.

Henry de Monfreid

Ungars a écritBonjour,
En changeant le canal de ton wifi ? J' ai eu ce problème récemment.

Ce n'est pas aussi simple.

On pense avoir 13 ou 14 canaux, mais vus qu'ils "débordent" sur les canaux voisins.

Comme tu vois, le canal 6, par exemple, squatte du canal 4 au canal 8, ce qui fait qu'au bout du compte, on a que 3 canaux disponibles ! 1, 6 et 11. Si les voisins proches de Billou ont un routeur sur chacun de ces canaux, ça ne servirait à rien.

Déplacer le routeur ou utiliser des antennes directionnelles serait plus efficace. Ou éventuellement utiliser le canal 14, si le matériel est compatible.