Description of problem: The adapter is recognized, but although the right driver is available in M8 (the rtl8192eu), the older rtl8xxxu is selected Version-Release number of selected component (if applicable): Manufacturer id 0x2001, device id 0x3319 How reproducible: Always Available workaround: blacklist in /etc/modprobe.conf the rtl8xxxu driver
Hi, thanks for reporting this. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Source RPM: (none) => kernel-5.10.16-1.mga8.src.rpmCC: (none) => ouaurelienSeverity: normal => majorStatus comment: (none) => Workaround blacklist in /etc/modprobe.conf the rtl8xxxu driverAssignee: bugsquad => kernel
not a bug as such. rtl8xxxu is the in-kernel maintained driver. the rtl8192eu driver is provided by dkms-rtl8192eu that is based on a realtek codedrop. for some the in-kernel driver works as it should... for others they need the dkms provided one... and what happends if you use the in-kernel driver ?
With the rtl8xxxu driver, the device does not detect any wifi possible connections. Defining a connection mannually does not result in a working connection.
any output in dmesg or journal when you try the rtl8xxxu ?
Nope
This is one of the bunch of < $10 realtek devices I bought for this kind of problems but unfortunately my local machine is dead. I can try to investigate this more after I get it replaced.
I finally got around to trying my rtl8192eu device with Mageia 8, and it does not work with the rtl8xxxu driver. My device will detect the available SSIDs, and will configure for my network, but will not connect. Blacklisting rtlxxxu allows it to work. This is the same behavior it has with Mageia 7. See Bug 27940. Unless the rtl8xxxu driver is blacklisted, the rtl8192eu driver will not be used.
CC: (none) => andrewsfarm
Created attachment 12490 [details] kernel log It indeed doesn't work. While running drakconnect I noticed this error which may be related: Error for wireless request "Set Encode" (8B2A) : SET failed on device wlp1s0u1 ; Invalid argument.
CC: (none) => pterjan
The error seems unrelated, it seems drakconnect insists to want it to be ascii but fixing it does not help.
Note that here using rtl-8192eu doesn't work either... [ 235.707615] ------------[ cut here ]------------ [ 235.707663] WARNING: CPU: 13 PID: 182 at net/wireless/sme.c:757 __cfg80211_connect_result+0x3db/0x420 [cfg80211] [ 235.707665] Modules linked in: xt_comment ip6t_REJECT nf_reject_ipv6 ip6table_nat ip6table_mangle ip6table_raw nf_log_ipv6 rfcomm ip6table_filter ip6_tables xt_recent nf_tables ipt_REJECT nf_reject_ipv4 xt_addrtype bridge stp llc iptable_nat xt_mark iptable_mangle xt_hashlimit xt_tcpudp xt_CT iptable_raw xt_multiport xt_conntrack nfnetlink_log xt_NFLOG nf_log_ipv4 nf_log_common xt_LOG nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter af_packet cmac algif_hash algif_skcipher af_alg bnep nls_utf8 nls_cp437 vfat fat dm_mirror dm_region_hash dm_log dm_mod rtsx_usb_ms rtsx_usb_sdmmc memstick joydev input_leds btusb btbcm btrtl btintel [ 235.707724] bluetooth ecdh_generic ecc usbhid iwlmvm snd_hda_codec_realtek 8192eu(O) snd_hda_codec_generic mac80211 ledtrig_audio snd_hda_codec_hdmi kvm_amd snd_hda_intel snd_intel_dspcfg libarc4 soundwire_intel kvm soundwire_generic_allocation snd_soc_core snd_compress snd_pcm_dmaengine soundwire_cadence irqbypass ite_cir snd_hda_codec iwlwifi rapl rc_core snd_hda_core ucsi_acpi eeepc_wmi ac97_bus cm32181 asus_wmi snd_hwdep typec_ucsi acpi_cpufreq battery cfg80211 typec sparse_keymap wmi_bmof button snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer r8169 snd snd_rn_pci_acp3x snd_pci_acp3x realtek soundcore mdio_devres ipmi_devintf libphy ipmi_msghandler rfkill hid_sensor_gyro_3d hid_sensor_accel_3d hid_sensor_als hid_sensor_magn_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common industrialio sch_fq_codel evdev mmc_block binfmt_misc mmc_core msr rtsx_usb fuse configfs efivarfs ip_tables x_tables ipv6 crc_ccitt autofs4 hid_sensor_hub hid_generic xhci_pci [ 235.707790] xhci_pci_renesas xhci_hcd ehci_pci crc32_pclmul crc32c_intel ehci_hcd ghash_clmulni_intel aesni_intel usbcore crypto_simd cryptd ccp amd_sfh sha1_generic usb_common amdgpu iommu_v2 gpu_sched ttm i2c_algo_bit drm_kms_helper wmi cec i2c_hid video hid drm [ 235.707817] CPU: 13 PID: 182 Comm: kworker/u32:2 Tainted: G O 5.10.25-desktop-1.mga8 #1 [ 235.707819] Hardware name: ASUSTeK COMPUTER INC. MINIPC PN50/PN50, BIOS 0611 12/17/2020 [ 235.707848] Workqueue: cfg80211 cfg80211_event_work [cfg80211] [ 235.707881] RIP: 0010:__cfg80211_connect_result+0x3db/0x420 [cfg80211] [ 235.707884] Code: fd ff ff 0f 0b 48 8b 44 24 18 65 48 2b 04 25 28 00 00 00 75 4b 48 8b 76 10 48 83 c4 20 5b 5d 41 5c 41 5d e9 27 30 fd ff 0f 0b <0f> 0b e9 0b fe ff ff e8 99 58 37 df e9 01 fe ff ff 0f 0b e9 30 fd [ 235.707885] RSP: 0018:ffffb166806e3df0 EFLAGS: 00010246 [ 235.707888] RAX: 0000000000000000 RBX: ffff9f4d023e6000 RCX: 0000000000000003 [ 235.707889] RDX: 0000000000000002 RSI: 00000000fffffe01 RDI: ffffffffc0d5aa4b [ 235.707890] RBP: ffff9f4d05501c18 R08: ffff9f4d047740c0 R09: ffffffff0001704e [ 235.707892] R10: ffff9f4d05501c88 R11: ffff9f4d023e6070 R12: ffff9f4d04772000 [ 235.707893] R13: ffffb166806e3df0 R14: dead000000000122 R15: dead000000000100 [ 235.707895] FS: 0000000000000000(0000) GS:ffff9f53ef940000(0000) knlGS:0000000000000000 [ 235.707897] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 235.707898] CR2: 00007f283805c7d8 CR3: 000000053660a000 CR4: 0000000000350ee0 [ 235.707900] Call Trace: [ 235.707935] cfg80211_process_wdev_events+0x139/0x1a0 [cfg80211] [ 235.707965] cfg80211_process_rdev_events+0x32/0x70 [cfg80211] [ 235.707994] cfg80211_event_work+0x1a/0x20 [cfg80211] [ 235.708000] process_one_work+0x1da/0x370 [ 235.708003] worker_thread+0x4d/0x3e0 [ 235.708006] ? rescuer_thread+0x3b0/0x3b0 [ 235.708037] kthread+0x11b/0x140 [ 235.708045] ? __kthread_bind_mask+0x60/0x60 [ 235.708053] ret_from_fork+0x22/0x30 [ 235.708059] ---[ end trace c0689c3a7c68b020 ]---
Kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=196769
According to https://github.com/clnhub/rtl8192eu-linux there is a new version of the rtl8192eu driver that, among other things, adds support for the upcoming 5.11 and 5.12 kernels. Perhaps we should update to that. Note also, in the readme section of that same page, the installation instructions make a point that the rtl8xxxu driver needs to be blacklisted for this driver to work.
I have ventured out of my comfort zone, and am lost. Someone with some developer know-how should be looking into this, not me. The driver from https://github.com/clnhub/rtl8192eu-linux is calling itself the "Official" Linux driver, and is based on the "latest" Realtek driver. The site indicates there has been much recent activity. Another driver, from https://github.com/Mange/rtl8192eu-linux-driver were created from drivers downloaded from TP-Link, which the page says are based on an earlier Realtek driver. This too shows recent activity, but not as much of it.
Realtek manufactures the chip inside those dongles, and distributes the driver to companies manufacturing them (DLink, TP-Link, ...) which redistribute it. Mange used to be the most up to date one (with 4.3.* and then 4.4.* drivers) but yes it seems a v5.2.19.1 of realtek driver appeared in 2018 which is the one available in lnhub. The most up to date one I could find is on Dlink website, from 2019: http://files.dlink.com.au/products/DWA-131/REV_E/Drivers/DWA-131_E1_Linux_v5.6.3.1/DWA-131_Linux_v5.6.3.1.zip
Which driver we offer boils down to which one we could have permission to distribute, and that isn't always the latest one...
I tested a dongle WiFi D-Link DWA-131 Rev E1. At plug in dongle was automatically recognize but couldn't connect it on my WiFi. In MCC the driver dongle was rtlxxxu. I installed non free driver dkms-rtl8192eu-4.4.1-1.20201219.1.mga8 but even this driver connection didn't made. After modify /etc/modules with 8192eu to load module into kernel, connection was effective. But if i want to connect it manually by press connect button in Drakconnect it doesn't work. Dongle connect wifi automatically...
CC: (none) => guillaume.royer
We stopped supporting Mageia 8 almost 8 months ago https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/ That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not. If this particular bug did not get fixed for Mageia 8, then we do regret that. If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field. If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing Mageia is a community project, meaning that we, the users, make Mageia together. The more active contributors we have, the more bug reports will get fixed. Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D
Resolution: (none) => OLDStatus: NEW => RESOLVED
I'm closing the report at Marja's request, I haven't tested this material on MGA9, as it no longer belongs to me.
Resolution: OLD => WONTFIX
My device uses the same chip as Herman's, and it does work in Mageia 9 with the dkms-rtl8192eu driver. At the time that Herman filed this bug, installing dkms-rtl8192eu did not automatically blacklist the rtl8xxxu driver. The user had to do that manually. That is no longer true, so the bug has been fixed. Sort of. Mageia 9 still tries to use the rtl8xxxu driver with this device if dkms-rtl8192eu isn't installed, and it still doesn't work with that chip. It would be nice if the system recognized that dkms-rtl8192eu was needed, and ask if the user wanted to install it, but that doesn't happen.
I'm sorry I made a mistake, in the notification queue I received, I thought it was a bug opened by me and I shouldn't have touched it... Is the bug reopened under MGA9?
No problem. I don't find a Mageia 9 bug for this, but I'd say the "won't fix" resolution is probably accurate.