Forum

Abandonné pour le moment,
Je possède un dongle WIFI modèle TL-WN823N version 2 qui ne fonctionne pas sous Magéia. Par contre fonctionne sous Ubuntu qui n'est pas ma distrib préférée!!! Fonctionne aussi sous Win XP avec les pilotes fournis.
Merci si vous pouvez trouver (quand même)une solution.

juin 2023
j'ai fait un petit post... problème résolu avec wpa_supplicant

Édité par relizane Le 09/06/2023 à 14h14

Comment ça, il ne fonctionne pas sous Mageia.
A-t-il déjà fonctionné ? Est-ce qu'il ne fonctionne plus ? Après quel type d'évènement ? Quelle version de Mageia ?

As-tu lancé la découverte de matériel du CCM ?

Édité par magnux77 Le 04/05/2019 à 22h34

Bonjour,

S' il fonctionne sous Ubuntu, il n' y a aucune raison qu' il ne puisse fonctionner sous Mageia...

Que donne la commande lsusb ?

Il faudrait regarder ce qu' indique le journal lorsque le dongle est branché ( par exemple dans un terminal lancer la commande ( en tant que root "journalctl -f )

que donne aussi un rpm -qa | grep rtlwifi-firmware (si ce ne répond rien, il faut installer le paquet rtlwifi-firmware (urpmi rtlwifi-firmware) après avoir éventuellement activé le dépot nonfree.

Bonjour,

Pour ajouter un module à l' arbre DKMS, il faut:

- installer dkms en utilisant le paquet adéquat ( si le pilote nvidia est installé ou virtualbox, c' est normalement déjà le cas)
- Les sources du pilote à compiler
- le kernel-desktop-devel qui correspond au noyau pour lequel on veut obtenir le module ( ici j' ai pris desktop, mais cela dépend du type de noyau installé ( uname -a permet de le savoir)
- un fichier dkms.conf dans le répertoire source du pilote

Une fois que l' on a ces éléments, il faut :

- copier les sources du pilote dans un répertoire source ( par exemple /usr/src )
- nommer ( renommer ) le répertoire par exemple sous la forme ,par exemple, nom_du_pilote-version_pilote ( on devrait donc avoir un /usr/src/nom_du_pilote-version_pilote)
- vérifier la configuration du fichier dkms.conf et l' adapter si nécessaire
- lancer la commande "dkms add -m nom_du_pilote -v version_pilote

Voir ici pour un exemple avec un autre pilote

Bonjour,

Que donnent


(afin de voir si le pilote est bien chargé) ?



A priori un pilote installé n' a pas de raison de disparaitre après un redémarrage de la machine.



Si c' est au travers de l' adaptateur wifi,alors il y a bien un pilote qui est chargé ( reste à voir si c' est bien celui qui a été compilé).

Si c' est bien le 8192eu qui est chargé, le problème est peut être plus à rechercher du coté de l' outil qui fait la connexion réseau.

Dans ce cas, il faudrait voir éventuellement ce que les logs indiquent lors de la tentative de connexion.
Pour cela, dans une konsole ( ou terminal), en tant que root il faudrait lancer la commande



et essayer de faire la connexion en parallèle.

note: cela ne resoudra pas le problème de dkms pour le moment...

Édité par nic80 Le 11/05/2019 à 18h36

Bonjour,

J' ai fait des erreurs dans le nom des commandes:

Au lieu de lusb, il faut lire lsusb
au lieu de journaltctl, il faut lire journalctl

Désolé pour ces erreurs de frappe.

je rajouterais la commande /sbin/modinfo 8192eu ( afin de voir si on a une information de version du module)

[url=Déjà, ne vaudrait-il pas mieux arriver à tout désinstaller pour reprendre à zéro? Comment faire?][/url]

Pour désinstaller le module installé manuellement, depuis le répertoire ou le module a été compilé, il faut faire un make uninstall (en root), afin de supprimer le module ajouté dans les noyaux disponibles.

Il faudrait aussi vérifier si le paquet dkms-rtl8192eu est installé ou non ( je ne sais pas s' il est compatible avec les noyaux 4.14). Eventuellement le désinstaller ( faire attention aux dépendances) pour éviter tout conflit.

Bonjour,

Concernant ma dernière phrase précédente, c' est parce que je vois que dans le dépot git indiqué, qu' il y a eu un fichier modifié en 2017 ( avec la mention "support kernel 4.14") alors que le paquet ne semble contenir que des fichiers de 2016.

Ceci dit:
- Peut être que paquet fonctionne
- Je ne sais pas s' il y a un support des versions 5.x.x du kernel ( version utilisée par Cauldron) par le pilote disponible dans ce même dépot git.

La procédure ci dessous n' est pas testée, n' ayant pas le matériel pour tester ( comme on touche aux modules cela pourrait potentiellement bloquer le démarrage de la machine) !

En tant que root dans un terminal:

- installer le paquet dkms si ce n' est pas déjà le cas ( "urpmi dkms")
- activer le service systemd ("systemctl enable dkms-autorebuild.service")
- installer le paquet kernel-desktop-devel correspondant au noyau utilisé ( uname -a pour voir la version (note: si c' est le 4.14.65 qui est installé, il me semble vieux ( la version actuelle est la 4.14.116-1 je crois))
- lancer la commande "modprobe -r 8192eu" , afin de décharger le module de la mémoire
- Dans le répertoire où a été compilé le module manuellement, faire un "make uninstall" , afin d' enlever le module compilé auparavant du répertoire /lib/modules/version_du_kernel
- supprimer le paquet dkms-rtl8192eu si installé ( "urpme dkms-rtl8192eu")

En utilisateur normal :

- Plutôt que d' utiliser la commande git clone, je téléchargerais le fichier zip directement ( bouton vert "clone or download" -> download zip), mais on peut garder le git clone ( le contenu devrait être le même que le fichier zip)
- Dezipper le fichier zip ( mais pas à l' endroit où le git clone a été fait, pour éviter un éventuel mélange des fichiers), si on choisi la méthode zip
- Si git clone est utilisé ( et que les fichiers originaux sont gardés), faire un "make clean" dans le répertoire du clone, afin de supprimer toute trace de compilation antérieure. Attention il est recommandé de faire le "make uninstall" avant le "make clean"
- Renommer le répertoire en rtl8192eu-linux-driver-realtek-4.4.x en rtl8192eu-4.4.1 ( le 4.4.1 est arbitraire de ma part, je ne sais pas quel numéro de version il faut utiliser)
- Ensuite modifier le fichier dkms.conf présent dans le répertoire pour mettre la variable package version à 4.4.1, et enlever la ligne REMAKE_INITRD=yes

En tant que root dans un terminal

- copier le répertoire de son emplacement original vers /usr/src ( "cp -r ~/rtl8192eu-4.4.1 /usr/src"), en supposant que le répertoire source téléchargé est à la racine du /home/relizane ( ajuster si nécessaire)
-Une fois ceci fait on peut faire un "dkms add -m rtl8192eu -v 4.4.1" pour l' ajouter à l' arbre DKMS ( auquel dkms devrait répondre quelque chose similaire à "DKMS: add completed"

Optionnellement,

- Faire un "dkms build -m rtl8192eu -v 4.4.1" , afin de lancer la compilation du module pour le noyau actuel
- Faire un "dkms install -m rtl8192eu -v 4.4.1", afin d' installer le module pour le noyau actuel
- Faire un modprobe 8192eu afin de charger le module en mémoire et voir si la connexion au wifi est possible depuis l' outil de configuration

Remarque: si les étapes optionnelles ne sont pas faites suite à la commande dkms add -m rtl8192eu -v 4.4.1 , elles le seront normalement au démarrage suivant de la machine (par le service autorebuild), le démarrage sera plus long du fait de la compilation du module

Considérer comme RESOLU (pour le moment)
install -p -m 644 8192eu.ko /lib/modules/4.14.116-desktop-1.mga6/kernel/drivers/net/wireless/ /sbin/depmod -a 4.14.116-desktop-1.mga6
[root@machine2 rtl8192eu]#
# Note:Le fichier compilé 8192eu.ko se trouve automatiquement inscrit dans /lib/modules/4.14.65-desktop-1.mga6/kernel/drivers/net/wireless/
[root@machine2 rtl8192eu ]# cd /
[root@machine2 /]# cd /lib/modules/4.14.116-desktop-1.mga6/kernel/drivers/net/wireless/
[root@machine2 wireless]# modprobe 8192eu.ko
modprobe: FATAL: Module 8192eu.ko not found in directory /lib/modules/4.14.116-desktop-1.mga6
[root@machine2 wireless]#

# j'espère que cela pourra servi pour dépanner?
Merci

Édité par relizane Le 06/10/2019 à 15h00

Bonjour,

La compilation s'est apparemment effectuée pour le kernel 4.14.116
=> MAIS

=> IL SEMBLE SE RETROUVER DANS LE 4.14.65
!!!!!

Attends l'avis de nic80 (je ne suis pas expert) mais réfléchis à tenter un modprobe depuis le répertoire 4.14.65... vers son correspondant 4.14.116 => ou alors, si une simple copie pourrait marcher (mv) -réussie chez moi pour un autre driver Realtek-.

Vérifie aussi que dans "/var/lib/dkms/rtl8192eu/" les fichiers de compilation aient été crées pour le chargement au boot.

A+

Bonjour,

Le git clone en root est peut être à éviter...

D' aprés les messages, le module semble être compilé pour le noyau 4.14.116 (sinon on aurait probablement des messages lors de l' installation du module ).

Si le but final est d' utiliser dkms, il ne faut pas faire de make, ni de make install puisque c'est dkms qui va s'en charger (au travers des lignes dans le dkms.conf).

@Nulix : copier des fichiers de modules d' un noyau à un autre c' est potentiellement s' exposer à des problèmes (par exemple des messages d' erreur concernant les symboles lors du chargement du module.

Je pense que la note sur le 4.14.65 est peut être une indication de la doc ou un commentaire lors d' une compilation précédente (mais en règle générale le module se compile pour le noyau en cours (d' ailleurs la ligne install indique bien une copie vers le 4.14.116).

@ rezilane: pour charger un module il n' y a pas forcement besoin d' être dans le répertoire où le module se trouve (modprobe va le trouver tout seul). En revanche, pas besoin de spécifier le .ko (ou le .ko.xz dans le cas d' un module compressé). Ici modprobe cherche 8192eu.ko.ko (8192eu.ko.ko.xz) qui n' existe pas... Si on utilise insmod il faut effectivement spécifier le nom complet (.ko compris)

Toujours dans l' optique d' utiliser dkms, le répertoire dans /usr/src doit être de la forme nom_du_module-version (sinon dkms risque de lancer un message d' erreur.)

Est ce que la procédure indiquée ne fonctionne pas ?

A priori, je l' ai effectuée sur une mageia 7 (donc avec un noyau 5.1.x) sans rencontrer de problèmes. Après, ma machine virtuelle n' ayant pas le matériel nécessaire je n' ai pas pu vérifier que ça fonctionne jusqu' au bout....

Édité par nic80 Le 16/05/2019 à 19h37

Bonjour nic80

Oui, tu as parfaitement raison. ...Je l'ai pourtant fait en désespoir de cause (pas moyen de charger le driver au bon endroit) la première fois que j'avais compilé mon driver wifi Realtek, à partir de sources de Ubuntu, et ça avait (étonnement) fonctionné sans problème.
Mais sans aucun doute possible, c'est à éviter.

Est-ce que vous voulez que je vous poste mon fichier (dkms-install.sh) de compilation automatique avec DKMS ?
Il n'y a, à mon avis, que quelques rectificatifs simples à y effectuer, pour le faire fonctionner avec cet autre driver.
- Il copie dans /usr/src
- Ajoute le DKMS
- Execute le build
- et installe donc en mode dkms, sans besoin de make, ni make-install, ni même modprobe.

Et puis, je m'aperçois que, dans le répertoire renommé "rtl8192eu" (au lieu de "rtl8192eu-linux-driver" ) les archives sources du 8192eu => se trouvent dans un répertoire nommé "usb"
/rtl8192eu/hal/rtl8192e/usb
alors que chez moi ce même répertoire correspondant s'appelle "pci"
/rtl8821ce/hal/rtl8821c/pci/
=> Jamais eu de répertoire "usb" dans aucune de mes 4 versions de driver, même pour kernels 4.x => Toujours "pci"
... A moins que s'agissant d'un dongle...

A+

Édité par Visiteur Le 16/05/2019 à 23h12

Pour le moment considérer comme RESOLU
Merci pour les réponses
je vais faire les essais
Par contre une erreur de ma part, la citation que j'ai faite est inexacte; en réalité:
# Note:Le fichier compilé 8192eu.ko se trouve automatiquement inscrit dans /lib/modules/4.14.116-desktop-1.mga6/kernel/drivers/net/wireless/
Toutes mes excuses
La commande modprobe 8192eu doit-elle donner une réponse; j'ai essayé avec modprobe -v 8192eu mais je n'ai que le prompt qui revient :
j'y retourne (bien que je comprenne toujours pas pourquoi la première installation toute simple a fonctionné deux jours avant que je n'éteigne mon ordi!)

Édité par relizane Le 06/10/2019 à 15h02

Bonjour,



A ma connaissance, non ( même si l' option -v devrait probablement afficher quelque chose d' après la doc)

Après pour vérifier s' il y a un changement avant/après, il faut faire un /sbin/lsmod | grep 8192eu ( pour voir si le module est chargé ou non).

edit: Sur ma machine virtuelle, u modprobe -v 8192eu me donne juste une ligne commençant par "insmod".

Édité par nic80 Le 18/05/2019 à 10h18

Considérer comme ...
Bonjour, toujours moi .. je ne vois pas ce qui cloche
j'ai abandonné pour le moment
Et merci pour le temps passé à me donner des conseils

juin 2023 problème résolu avec wpa_supplicant

Édité par relizane Le 09/06/2023 à 14h15