Le sans fil continue de couper toutes les quelques minutes sur un Realtek RTL8187SE

Internet continue de se couper toutes les quelques minutes, parfois il dure plus longtemps mais cela arrive finalement. Je peux toujours utiliser Internet si je me déconnecte du menu et que je clique à nouveau sur Connexion. Toute aide serait appréciée :)

Détails de ma carte sans fil:

Carte sans fil: 04: 00.0 Contrôleur réseau: Realtek Semiconductor Co., Ltd. RTL8187SE Wireless LAN Controller (rev 22)

Je suis juste en train d'exécuter un ancien Ubuntu 64 bits entièrement à jour (noyau 2.6.38-10-générique)

Comment le noyau reconnaît ma carte sans fil:

*-network               
       description: Wireless interface
       product: RTL8187SE Wireless LAN Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:04:00.0
       logical name: wlan0
       version: 22
       serial: 00:24:21:cf:89:f6
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=r8180 latency=0 multicast=yes wireless=802.11b/g
       resources: irq:17 ioport:3000(size=256) memory:fa000000-fa003fff
  *-network
       description: Ethernet interface
       product: RTL8111/8168B PCI Express Gigabit Ethernet controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:05:00.0
       logical name: eth0
       version: 03
       serial: 00:03:0d:de:97:eb
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.67 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:43 ioport:4000(size=256) memory:f6000000-f6000fff memory:f4000000-f4003fff memory:f4020000-f403ffff

J'utilise simplement un gestionnaire de réseau standard, rien de vraiment personnalisé.

Les connexions WiFi interrompues peuvent être liées à l'environnement ou au logiciel.

Je vais essayer de garder cela aussi générique que possible, afin que la réponse puisse s'appliquer à toutes les cartes WiFi.

Trois domaines environnementaux que vous devriez considérer avant de vous plonger dans les suggestions de logiciels ci-dessous:

• Cryptage WIFI - Essayez de changer la méthode de cryptage sur votre routeur WIFI, voyez si cela se traduit par une connexion plus stable.

• Routeur WIFI lui-même - Essayez de passer à un nouveau point d'accès, avez-vous toujours des problèmes de connectivité?

• Canal WIFI - Essayez de changer le canal sur lequel votre routeur communique. Dans votre région, il peut y avoir trop de trafic sur la chaîne que vous avez sélectionnée.

Une fois que vous avez exclu ces domaines, cinq pistes logicielles possibles que vous pourriez envisager:

1. Vous cherchez à voir si un backport WiFi existe et si oui, installez le package approprié
2. Voir s'il s'agit d'un problème 64 bits vs 32 bits
3. Essayer un nouveau noyau, soit le prochain noyau stable disponible OU tester la toute dernière version alpha / bêta d'Ubuntu qui contient le dernier noyau candidat de la version
4. Désactiver la gestion de l'alimentation de votre carte sans fil
5. (le choix du tout dernier recours) en utilisant NDISWrapper

Backports

Les développeurs du noyau publient souvent un progiciel contenant des mises à jour pour les appareils WiFi dérivés du noyau le plus récent ou le plus récent.

Pour Natty, ce paquet s'appelle linux-backports-modules-cw-2.6.39-generic(merci Jorge). Ce package peut être trouvé dans le référentiel proposé ou dans le référentiel backport. Cochez la case appropriée dans Sources de logiciels et rechargez les dernières mises à jour.

Ouvrez le Centre logiciel ou Synaptic Manager et recherchez le package nommé (ou similaire) comme ci-dessus. Si le package est disponible, installez-le, redémarrez et voyez si la connexion WiFi est plus stable.

64bit vs 32bit

À mesure que Linux mûrit, les problèmes 64 bits contre 32 bits devraient diminuer. Cependant, il n'est pas inconnu qu'une installation 64 bits peut être plus instable par rapport à une installation 32 bits - et vice-versa.

Pour votre carte, j'ai trouvé ici un rapport de bogue pour votre carte sans fil qui décrit vos symptômes - noyau 64 bits, wifi abandonne la connexion au hasard.

Faites d'abord une copie de sauvegarde de votre système en utilisant, par exemple, Clonezilla, afin que vous ayez quelque chose que vous puissiez facilement restaurer.

Essayez d'installer la version 32 bits de Natty. Vérifiez si votre connexion est plus stable. Vous pouvez également tester les autres suggestions de cette réponse dans cette configuration 32 bits.

Nouveau noyau

Tester un noyau plus récent peut parfois provoquer des problèmes d'instabilité - par exemple des problèmes de démarrage et d'écran noir. Je vous recommande de supprimer tout pilote graphique matériel supplémentaire (par exemple ATI ou Nvidia) en premier. Je recommande également que vous ayez une bonne sauvegarde par exemple, en utilisant CloneZilla à partir de laquelle vous pouvez restaurer.

Recherchez le prochain noyau stable principal à partir d' ici sur LaunchPad .

En regardant les listes de modifications sur le noyau 2.6.39, il mentionne quelques mises à jour pour votre carte.

Vous pouvez installer le noyau 2.6.39 comme décrit dans ma réponse ici .

Désactiver la gestion de l'alimentation

Parfois, les cartes sans fil peuvent avoir des modes de gestion de l'alimentation. Ce n'est pas inconnu pour que ces modes soient bogués sous Linux. La désactivation de la gestion de l'alimentation peut parfois être utile.

Vous devrez peut-être effectuer des recherches sur Google pour voir s'il existe une méthode spécifique pour désactiver la gestion de l'alimentation. Voici une méthode que j'ai utilisée dans le passé pour certaines cartes.

À partir d'un type de terminal:

gksu gedit /etc/pm/power.d/wireless

Si le fichier ouvert contient des instructions, ajoutez la ligne suivante (si elle n'existe pas déjà)

/sbin/iwconfig wlan0 power off

Si le fichier ouvert est vide, ajoutez ce qui suit

#!/bin/sh

/sbin/iwconfig wlan0 power off

Copiez et collez maintenant les éléments suivants:

sudo chmod +x /etc/pm/power.d/wireless

Redémarrez ensuite.

la source

NDISWrapper

Remarque - NDISWrapper peut provoquer des problèmes d'écran noir au démarrage - ayez donc une bonne sauvegarde par exemple, en utilisant CloneZilla à partir de laquelle vous pouvez restaurer.

Il y a quelques années, NDISWrapper était une méthode fréquemment utilisée pour les cartes sans fil car le noyau avait si peu de support pour les pilotes sans fil.

Il est tombé en disgrâce ces derniers temps pour de nombreuses raisons que je n'entrerai pas dans ...

Pour être honnête, RTL8187se est dans le noyau depuis un certain temps, donc la suggestion suivante doit être considérée en dernier recours.

Recherchez ndisgtkdans le centre logiciel et installez

Téléchargez maintenant les pilotes Windows XP , dans votre cas depuis Realtek

Extrait du fichier zip.

Utilisation de ndisgtk - accédez au dossier - RTL8187SE - WinXP et pointez ndisgtk vers le .inffichier. Avec un peu de chance maintenant (peut-être après un redémarrage) le gestionnaire de réseau devrait utiliser ce pilote de préférence au pilote du noyau RTL8187SE - nb espérons que vous n'ayez pas à mettre la liste noire du noyau sur liste noire.

Cela ressemble à un problème que j'habitais à Meego (non pas Ubuntu) où le wifi se coupait et se coupait tellement que c'était vraiment une douleur.

Je me souviens à l'époque qu'il avait été corrigé en éditant le fichier rc.local avec un correctif vraiment facile qui fonctionnait (quoique dans Meego) mais

cd /etc/

gksudo gedit rc.local

Insérez les lignes suivantes si elles ne sont pas déjà là (ou décommentez-les)

ifconfig wlan0 down
ifconfig wlan0 up

(à l'origine dans l'ancien bug meego, nous devions changer wlan0 en eth1 (je ne sais pas pourquoi, mais cela signifiait que nous utilisions eth1 et non wlan0)

vieux bug meego

MAIS c'était un problème de broadcom mais il semblait un peu similaire à ce que vous décriviez