Non, je n’ai pas réussi à le compiler.
Je dois obtenir un .bin à remplacer, comme avec l’autre pilote, avec l’ancien se trouvant dans /lib/firmware ?
Hum, non je ne pense pas. Je pense que tu vas obtenir un fichier .ko, (un module) qu’il faudra charger à la place de celui qui doit être actuellement utilisé (via la commande modprobe).
Mais tout doit être expliqué pas à pas dans le readme.
Tu bloques à quel moment de la compilation ?
Je ne sais pas si je bloque vraiment, je me suis contenté de taper « make » dans un terminal, dans le dossier du driver.
Par contre, j’ai, dans archive/os/linux/ un rt2860sta.ko et un rt2860sta.o.
Donc c’est bon à priori ?
Ma foi, je dirais que oui ! La compilation a réussi et t’a généré le nouveau module (2 en fait, le ko pour les noyaux 2.6 et >, et un .o pour les noyaux 2.4).
Maintenant faut le charger, mais avant faut décharger l’autre :
lsmod |grep nom_du_moduleSi ca ramène un résultat :
rmmod nom_du_moduleon vérifie qu’il est bien déchargé, la commande suivant ne doit rien ramener :
lsmod |grep nom_du_modulepuis tu charges le nouveau :
cd /chemin/os/linux
insmod nom_du_module.koon vérifie qu’il est bien chargé
lsmod |grep nom_du_moduleN’oublie pas de copier le fichier.dat de l’archive aussi, à la place de celui que je t’ai trouvé hier.
Si c’est ok : démonte et remonte le wifi (ifdown wlan0 / ifup wlan0), redémarre aussi le gestionnaire de wifi tant qu’on y est. Puis vois si c’est mieux…
J’avais oublié un « make install » dans l’archive, ce qui copie directement le module et le .dat dans le bon dossier, etc.
Bref, après reboot, le module chargé est bien en version 2.4 contre une 1.8 (je crois) auparavant.
Je vais voir s’il y a des améliorations. Merci !
OK, en fait mes commandes auraient permis de tester le nouveau module avant de le fixer en dur si le test eut été concluant, mais si c’est fait, alors c’est plus à faire 
Rien à signaler depuis le reboot de l’ordinateur, c’est tout bon jusque là.
Merci encore, j’espère que cela va durer.
Et voilà, encore une coupure avec la même erreur 
ERROR!!! RTMPCancelTimer failed, Timer hasn’t been initialize!
Je pense qu’il y a quand même du mieux par rapport à avant, je n’ai pas eu de coupure hier ni ce matin durant deux heures. En tout cas, après la coupure, j’ai pu me reconnecter en dix secondes, avant je devais attendre dix minutes, donc c’est déjà ça.
J’essaierai de trouver le moyen (avec un script peut-être) d’enregistrer toutes les coupures dans un fichier texte sur une journée histoire de voir le niveau de stabilité de ma connexion. Si quelqu’un a un script déjà tout fait, n’hésitez pas 
.
Jette un oeil la dessus :
bugs.launchpad.net/ubuntu/+sour … bug/496093
Y aurait une modif à apporter sur le code source du driver, au niveau du fichier /…/os/linux/config.mk, qui résoudrait ces problèmes de déconnexions qui semblent inhérents à la gestion du WPA :
Support Wpa_Supplicant
HAS_WPA_SUPPLICANT=y (remplacer n par y)
Support Native WpaSupplicant for Network Maganger
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y (remplacer n par y)
Sauvegarder, recompiler et réinstaller le module. Rebooter (ou démonter/remonter le réseau).
J’ai un problème aussi de carte wifi avec débit ultra lent et mauvaise qualité de connexion. Mais la cause n’est pas la même, je n’ai pas la même erreur.
Si ça peut t’aider il m’a suffit de désactiver la gestion de l’énergie:
iwconfig wlan0 power off
Pour enregistrer les coupures sur une journée, il suffit de grepper le fichier /var/log/messages (ou syslog je ne sais plus…) sur une date et l’intitulé de l’erreur.
cat /var/log/syslog |grep "Oct 8" |grep "ERROR!!! RTMPCancelTimer failed, Timer hasn't been initialize!" >> coupure_connection.txtTu lance ça à la fin de la journée. Tu peux même faire des stats avec les jours précédents du coup, en changeant la date dans le premier grep.
OK merci à vous.
Je vais prendre le temps de regarder tout ça et je vous informerai du résultat.
J’ai laissé allumé mon PC toute la journée et j’ai rencontré au total une vingtaine d’erreurs (cancel timer failed, etc.), avec le nouveau module et les options WPA activées lors de la compilation (bien que j’utilise WEP).
C’était un peu mieux que les autres jours, sauf ce soir où j’ai encore dû attendre 15 minutes avant de retrouver ma connexion.
Pour le système d’énergie, je ne peux pas le (dés)activer :
Error for wireless request “Set Power Management” (8B2C) :
SET failed on device wlan0 ; Operation not supported.
Je ne sais pas quoi te faire faire de plus… T’es sur que ton access point est fiable ?
Je vais regarder de ce côté là, peut-être en restant quelques heures sur un wifi public.
En tout cas, j’ai encore eu une dizaine d’erreurs hier, mais c’est globalement mieux qu’avant.
Merci en tout cas, je constate tout de même une nette amélioration de ma connexion grâce à toi. J’essaierai de suivre l’évolution du driver histoire de mettre toutes les chances de mon côté.
Bonjour à tous !
Après quelques soucis, j’ai réinstallé Debian et je suis passé sous KDE. Je me suis vite débarrassé de Network Manager qui se déconnectait tout seul sans donner de véritable raison, pour le remplacer par Wicd.
Je viens de remplacer le service dhcp (anciennement dhclient) pour dhcpcd et j’ai également paramétrer des DNS statiques avec OpenDNS.
Comme sur mon ancienne installation, ma connexion n’est pas stable : elle coupe environ toutes les heures. Néanmoins, les logs différents assez :
> cat /var/log/syslog
Oct 28 16:25:39 debian dhcpcd[5972]: wlan0: dhcpcd not running
Oct 28 16:25:39 debian dhcpcd[5972]: wlan0: exiting
Ceci se produit assez aléatoirement : tout va bien dans mon log, et sans aucune raison ces deux lignes apparaissent, me laissant sans connexion pendant 10 minutes, le temps que tout se remette en place, et rebelote 30 minutes après.
Merci à vous,
Graphox.
Bonjour,
Aujourd’hui, ma connexion a beaucoup plus de mal à se stabiliser après ces erreurs, d’autant plus que, dorénavant, j’obtiens des messages :
Oct 29 08:06:37 debian dhcpcd[5417]: eth0: dhcpcd not running
Oct 29 08:06:37 debian dhcpcd[5417]: eth0: exiting
Je ne sais pas s’ils arrivent lorsque Wicd cherche à switcher vers une connexion filaire, mais en tout cas, il n’a pas l’air d’aimer dhcpcd… Mais en ai-je vraiment besoin étant donné que j’utilise des IP et DNS statiques ?
Chose étrange, ma connexion arrive à se stabiliser (rien qu’à la première connexion) sans m’embêter pendant 30 minutes avec son dhcpcd, et après, c’est toutes les 5 secondes.
Graphox.
Salut,
Au cas où… as-tu essayé avec un autre noyau ?
Merci pour ta réponse.
Lors de l’installation de Debian, j’avais le noyau 2.6.26. Néanmoins, je savais qu’il ne prenait pas en charge mon pilote. Comme il me fallait KDE 4.4, j’ai décidé de passer le système en Squeeze et le noyau 2.6.32-5 s’est installé (mes autres problèmes se produisaient sur un 2.6.34).
Je devrais donc prendre un noyau encore moins stable ?