Description of problem: Did the recommended security update - new kernel 4.4.13-1-mageia, broke Wifi connection Version-Release number of selected component (if applicable): 4.4.13-1 update pushed late evening 13 june 2016 CET. How reproducible: Rebooted with old kernel 4.1.x and WiFi works fine, reboot again to kernel 4.4 and no WiFi connection. Had to reconnect the WiFi applet so the tray icon looks like its connected but no real connection is established to network using Chromium browser. Steps to Reproduce: 1. Update kernel from 4.1 to 4.4 on Lenovo ThinkPad T61 Type 6460-8NG 2. Reboot 3. No WiFI (Intel 4965 AG) 4. Reboot old Kernel 4.1 and the WiFi works again. 5. Reboot new Kernel 4.4 and the WiFi don't work.
I am using Mageia 5 Xfce 64-bit. The network applet says it has established a good WiFi-connection but there is no network traffic. When connecting Ethernet LAN cable it switches over to wired network and internet is working again. Remove the LAN cable and the applet is correctly switching back to WiFi - but network traffic is lost.
Assignee: bugsquad => tmb
Please boot into kernel 4.1.x, open terminal window, "su -" to root and do journalctl -b >bug18703-4.1.txt Then boot into kernel 4.4.13, open terminal window, "su -" to root and do journalctl -b >bug18703-4.4.txt And _attach_ both files (bug18703-4.1.txt and bug18703-4.4.txt) to this bugreport
Keywords: (none) => NEEDINFOSource RPM: Kernel 4.4.13-1-mageia => kernel-4.4.13-1.mga5
Created attachment 7992 [details] Bootlog bug18703-4.1.txt
Created attachment 7993 [details] Bootlog bug18703-4.4.txt
Ok, attached requested logs.
Ok, seems udev is renaming the interface differently on 4.4 series compared to 4.1 series for some reason... on 4.1.15 I see: jun 14 17:45:56 localhost kernel: iwl4965 0000:03:00.0 wlp3s0: renamed from wlan0 on 4.4.13 I see: jun 14 17:50:48 localhost kernel: iwl4965 0000:03:00.0 wls3: renamed from wlan0 so the interface name went from "wlp3s0" to "wls3" wich means if you use the firewall it wont pass the traffic... Easiest way is to reconfigure the firewall to recognize this new name (or add it as an additional name in case you want to boot an older kernel again
Keywords: NEEDINFO => (none)
You're not going to fix the different udev renaming? Am I the only one affected?
Turned the firewall off and I could surf the web on kernel 4.4.13 Turned the firewall back on and klicked advanced and then ok and then both wlp3s0 and wls3 was preset alongside the ethernet port. I can now surf the web on kernel 4.4.13 with the firewall up. In other words turning the firewall off and on fixed the problem - knock on wood.
Its not that easy... And yes I think this is related to your system... udev names the interfaces according to what kind of info it gets from bios, dmi and acpi tables and so on ... and for some reason eems your hw responds differently when probed at different times... And now reading your logs again I see it tried to pull up a "wls3" interface on your 4.1.15 kernel too, but then the "wlp3s0" got active first, so the "wls3" failed... So seems there is some extra configs or something on your system ... If that comes from some broken hw or if its something you have tested I cant say.. and come to think of it, the "wls3" seems more like a "biosdevname", a fallback that gets activated in case udev cant get full system info for some reason... So I suggest you remove all wireless interface configs, reboot and try to reonfigure your wireless.. Hopefylly it will keep stable after that... If not, you can do a manual override by editing: /etc/udev/rules.d/70-persistent-net.rules and add a line: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="54:52:00:ff:ff:de", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlp3s0" Just ensure the "ATTR{address}" part matches the MAC address on your wireless card (you can see it with ifconfig)
Thank you for your help! :)
Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.
Assignee: tmb => kernel
Closing as OLD, because Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, but non-security bugs have no chance of still getting fixed. Besides, IIUC it is more likely that this was a hardware issue than a Mageia bug.
CC: (none) => marja11Resolution: (none) => OLDStatus: NEW => RESOLVED