Created attachment 11458 [details] Results journactl and iwlist Hello There was a wifi/Kernel problem solved by the https://bugs.mageia.org/show_bug.cgi?id=25926 bug. But I still have another wifi connection problem that doesn't work in a university environment, where the wifi connection is done via a browser. Several "SmartCampus" networks of different intensities are listed. The system for the wifi connection therefore sees several antennas and after connecting, my computer disconnects after a period of time that varies between a few seconds and several tens of minutes. I tested several commands after I started the computer and lost the connection. journalctl -b0 | grep wlo1 journalctl -b0 | egrep "wlo1|iwlwifi" iwlist wlo1 scanning You can see the connection on 40:18:b1:6a:51:54 and then the lost. It's consistent with Cell 03 Thank you for your help.
Thank you for the evidence you attached. Can you please say how long this problem has existed? - Since the system was installed or upgraded to M7; - After a more recent system update - and if so, can you pin that down? Especially kernel updates. Assigning to kernel/drivers.
CC: (none) => lewyssmithAssignee: bugsquad => kernel
Hi Lewis, The ASUS computer (S512FA-EJ726T) is new (December 2019). The Mageia 7 installation is new (end of December 2019), and Windows 10 deleted. The Windows 10 license has been refunded by Asus. From the beginning, the wifi didn't work properly : 1) The wifi did not work with a box in a house (instability). 2) The wifi didn't work, except sometimes very difficult with the university system wifirst.com and the smartcampus solution (very very unstable). 1) has been fixed thanks to the bug deposit 25926 on 2019-12-22. The new kernel-desktop-5.4.6-1.1.mga7 has solved 1). The history of kernel and iwlwifi tests is visible in bug 25926. https://bugs.mageia.org/show_bug.cgi?id=25926 The 2) has not been solved with the new Kernel. The situation today: Operating system: Mageia 7 KDE Plasma Version: 5.15.4 KDE Frameworks version: 5.57.0 Version of Qt: 5.12.6 Kernel version: 5.4.6-desktop-2.mga7 Operating system type: 64-bit Processors: 8 × Intel® Core™ i5-8265U CPU @ 1.60GHz Memory: 7.6 Gio of memory iwlwifi-firmware 20191220 Thank you for your help. Note: I phoned wifirst, but the technicians can't help for Linux...
> 1) The wifi did not work with a box in a house (instability). > 1) has been fixed thanks to the bug deposit 25926 on 2019-12-22. > The new kernel-desktop-5.4.6-1.1.mga7 has solved 1). Good, some progress.
CC: lewyssmith => (none)
Yes Lewis, but it is impossible to use the computer in the university (laboratory and housing). Anyway, it's more than annoying...
Hi Lewis, Did you see that 1) has been set since 2019-12-22 ? And that since then we can't connect the computer to the university. That's problem number 2. So the computer has been unusable with Mageia for a month?
Hello, The computer is still unusable at the university. All the latest updates (Kernel and others) have been made. Do you need information or tests?
Note that many small hotels/motels with small ranges for DHCP addresses compared to their room count have the despicable habit of dropping assignments which have been idle for a certain period of time or which have transmitted or received a certain amount of data. Maybe your uni is doing something similar ? But this is most likely your problem: >janv. 14 09:12:42 localhost.localdomain kernel: iwlwifi 0000:00:14.3: Conflict between TLV & NVM regarding enabling LAR (TLV = enabled NVM =disabled) You can use NVM (Network Manager) or MGA stuff (net-applet), but it's apparent from recent bug reports and posts that they don't get along as well as they used to. See https://bugs.mageia.org/show_bug.cgi?id=26035 .
CC: (none) => ftg
(In reply to Frank Griffin from comment #7) > > But this is most likely your problem: > > >janv. 14 09:12:42 localhost.localdomain kernel: iwlwifi 0000:00:14.3: Conflict between TLV & NVM regarding enabling LAR (TLV = enabled NVM =disabled) > > You can use NVM (Network Manager) or MGA stuff (net-applet), but it's Nope, this message states that the Location Aware Regulatory should be enabled according to tlv config, but the info stored in Non-Volatile Memory states it should be disabled. if you still have /etc/modprobe.d/iwlwifi.conf with the line: options iwlwifi lar_disable=Y remove it. If you dont have it, try to add it.... Now it's a stop-gap test as the option will be removed in upcoming 5.5 series kernels... but it's worth to try now... You could also try with the latest 5.3 series kernel we have in updates... Now theese issues are known upstream, and there is several reports in several distro bugtrackers about buggy iwlwifi for some in 5.4 series kernels... but it's only Intel guys that can sort it out... some bits might need new firmware, other bits will be code changes... I have already added all the known fixes confirmed by Intel guys so far in our kernels... On can only hope that switching to 5.5 series will bring some stability back to iwlwifi for affected users...
CC: (none) => tmb
Hi Frank and Thomas, Thank you for your answers! - The Asus connections are managed by net_applet. There is a question about this: could using networkmanager solve the problem? Or would it complicate connection management even more? (Switching from one to the other doesn't seem so easy to me). - Both configurations have been tested for /etc/modprobe.d/iwlwifi.conf with the line: options iwlwifi lar_disable=Y . With or without, the connection is unstable at the University. - Question : is there a way to "force" the connection to an antenna by putting its ESSID, etc in a file? If so, which file should be modified? Attached is a picture 1 of a connection to smartcampus when the connection is working. There is also a picture 2 when the connection is then lost. - Currently the version used is Operating System: Mageia 7 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.6 Kernel Version: 5.4.12-desktop-1.mga7 OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8265U CPU @ 1.60GHz Memory: 7,6 Gio
Created attachment 11474 [details] lost connection
Created attachment 11475 [details] OK connection ESSID etc
NM will automatically connect to any ESSID to which you have connected previously (so, I think, will net-applet). For new ESSIDs you have to use either plasma-net-applet or nmtui to connect the first time.
Hi Frank, What I was thinking about is to specify to which antenna I want my computer to connect. For example, I had previously tried to modify the file /etc/wpa_supplicant.conf by adding the following lines: network={ ssid="SmartCampus" bssid=40:18:B1:6A:51:54 } But this doesn't work: my computer still connects to antennas different from the one I specified (for example, antennas with low intensity, which makes the connection even more unstable). Hence my question: is there another way to force the computer to connect to a given antenna?
Hi, Since the last update, the wifi doesn't work anymore. I found a table gathering some information about the Cannon Point-LP CNVi [Wireless-AC]: https://www.linux-hardware.org/index.php?id=pci:8086-9df0-8086-0034&page=1#status
I have been battling Mageia on an Auss Zenbook UX333, with teh Cannon Point wireless.. It seems that one has to use the kernel-firmware-20190603 version AND iwlwireless-firmware-20190603. For some reason for both the Mageia install put in 20190704 which did not work. Of course it is not easy, since I had to boot to Windows each time to download (since wireless was all I had). There is a claim that the 5.7 kernel includes support natively, but trying to install it fron Cauldron, I got that it asked for almost all of the drak tools to be uninstalled. Why in the world the draktools had anything to do with the kernel I have no idea. (Note that the 5.7 kernel installed fine on two other Mga7 machines without asking for all of the drak tools to be unloaded, but then those two had been updated.) Anyway, I got the wireless working by using the 20290603 versions of the firmware, but am now fearful of updating the machine as that might destroy the working of Mga7 again on this machine.
CC: (none) => unruh
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Status: NEW => RESOLVEDResolution: (none) => OLD