Bug 17461

(In reply to Palm Pre from comment #0)
> Description of problem: Every time I close the lid on Dell Latitude D630,
> Wi-F1
> connection turns off. When the open the lid again, it doesn't connect
> automatically. I had to run #drakconnect to make it work. 
> 

Do you mind attaching the journalctl output (as root) from when you close the lid until some time after you open it again (but before you manually restart the connection)?

You said you use Gnome, I suppose you did not remove or disable NetworkManager in favour of drakxnet, did you?

CC: (none) => marja11
Keywords: (none) => NEEDINFO

I waited about 10 min.  #journalctl shows just 43 lines and terminal stops there. I'll attach file with output.

From GNOME setting Network shows only "proxy" option. MCC has Network Center where I probably can turn WiFi on.

Created attachment 7333 [details]
#journalctl - 43 lines with no WiFi

(In reply to Palm Pre from comment #3)
> Created attachment 7333 [details]
> #journalctl - 43 lines with no WiFi

Please try again, let's say you closed the lid on 
2016-02-14 10:05h and opened it on 
2016-02-14 10:50h (and don't manually restart the wlan connection before 11:00)

then I'd be interested in journal.txt that is the result of (as root)

 journalctl --since "2016-02-14 10:00" --until "2016-02-14 11:00" > journal.txt

so from a few minutes before till 10 minutes after the lid was closed, without manually restarting the network service or connection

Thanks :-)

The box was off for couple of hours. I try to do it for lid closed and opened 10 min ago. No connection

After reading your suggestions, I'll try "open, connect, close, and open again" journal1.txt

Created attachment 7457 [details]
Lid closed for a long time and opened with no connection

Created attachment 7458 [details]
lid open with connection, closed - connection lost, open in about 2 min - no connection

The new attachments are much better :-)

after opening the lid, when wlan doesn't work, what is the output (as root) of

  systemctl status network.service

and of 

  systemctl status networkmanager.service

Created attachment 7464 [details]
systemctl status network.service and systemctl status networkmanager.service

@ Palm Pre

Can you try whether after reopening the lid, doing (as root)

  systemctl restart network.service 

correctly enables your wlan connection again?


@ all whom I just CC'ed

can one of you take over from here?

in attachment 7457 [details] and attachment 7458 [details] I don't see any lines containing
 localhost.localdomain network[<some pid>]

shouldn't they exist?

in attachment 7464 [details], there's isn't even anything recent about network.service.

I do not know to which package to assign this bug

CC: (none) => mageia, olav, pkg-bugs, thierry.vignaud, tmb

(In reply to Palm Pre from comment #2)
> I waited about 10 min.  #journalctl shows just 43 lines and terminal stops

FWIW, if you run journalctl without any options, it will open the journal for the current boot in a pager, meaning you would only see the first page of the log and you need to scroll down, as indicated by the bottom line

> lines 1-43

It would be better to run "journalctl -abf" which means show all entries and overlong lines (-a) only for the current boot (-b with no arguments) and -f to follow the journal entries, so they will be shown on screen as they are logged as long as you leave that command running.

In general, it seems before the suspend the only thing that happens regarding wifi is that you wireless adapter deauthenticates from the AP:

> Feb 14 13:15:01 localhost.localdomain kernel: wlp12s0: deauthenticating from 74:44:01:39:76:c4 by local choice (Reason: 3=DEAUTH_LEAVING)

Then after the system resumes from suspend, it notices a bit later that the network interface went down, and nothing seems to reenable it.


From the attachments, seems you're using net_applet and not networkmanager, but let's take a further look. Please provide some more details, as root post the output of:


rfkill list all
ps -ef|grep -v grep|grep -iE "net|wpa"
lspcidrake -v|grep -iE "wlan|wifi|wireless|net"
journalctl -ab | grep -iE "fw|firmware|iwl|wifi|wire|80211"


The last one preferrably as an attachment as it might be longer.

CC: (none) => doktor5000

It looks like I can start Network manager from MCC. From Gnome settings I have "proxy" as the only option so I'm using #drakconnect.

I'm adding two attachments: rfkill includes first three lines; journal -ab - the last one.

Created attachment 7473 [details]
rflkill and two more root outputs

Created attachment 7474 [details]
long output of journal -ab

For the long journalctl -ab output, it would be helpful if you could add when you closed the lid, or when wifi was working and when not for a few timestamps. Do I assume correctly that each time when it didn't work, you run drakconnect to "re-configure" the wireless interface and it worked again afterwards?

(In reply to Palm Pre from comment #12)
> It looks like I can start Network manager from MCC. From Gnome settings I
> have "proxy" as the only option so I'm using #drakconnect.

No need to start networkmanager, there's more needed to use it instead of net_applet if you want that. I've described how to switch from Mageia's default net_applet to networkmanager here: https://forums.mageia.org/en/viewtopic.php?f=25&t=5782


I'd suggest you try to blacklist the dell-wifi module, which also shows as an additional interface in rfkill output. You can do so as root via

echo "blacklist dell-wifi" >> /etc/modprobe.d/blacklist-dell.conf

and then try again to close the lid after a reboot.

It would be good if you can also add the output as root of

lsmod|grep dell

And please don't add such short outputs directly in your reply, and not as an attachment.

The one I can do fast

# lsmod|grep dell
dell_wmi               16384  0 
sparse_keymap          16384  1 dell_wmi
dell_laptop            20480  0 
dcdbas                 16384  1 dell_laptop
rfkill                 24576  6 cfg80211,bluetooth,dell_laptop
wmi                    20480  1 dell_wmi
# 


General question: what do you call network manager and what is net_applet?

Created attachment 7482 [details]
lid closed, opened, and connected to internet with #drakconnect

Blacklisted "dell-wifi", reboot wifi is on with lid open. Closing lid, waiting about minute wifi is off. It's difficult to give exact timing. I may do it sometimes later. Creating another attachement.

Created attachment 7483 [details]
no wifi at the end

I suspect this is another case of the crappy support for wifi with the net_applet tools.

I'd seriously consider switching to Network Manager as noted in comment 15. It's far superior to our aging tools and will hopefully be the default in MGA 6.

(In reply to Palm Pre from comment #16)
> # lsmod|grep dell
> dell_wmi               16384  0 

Ahh okay, so you need to blacklist dell_wmi and not dell-wifi. As root

echo "blacklist dell_wmi" > /etc/modprobe.d/blacklist-dell.conf

This general issue with such wmi modules is also mentioned at https://wiki.mageia.org/en/Setup_wireless_networking#known_issues_with_specific_drivers

> sparse_keymap          16384  1 dell_wmi
> dell_laptop            20480  0 
> dcdbas                 16384  1 dell_laptop
> rfkill                 24576  6 cfg80211,bluetooth,dell_laptop
> wmi                    20480  1 dell_wmi
> # 
> 
> 
> General question: what do you call network manager and what is net_applet?

network manager is network manager: https://wiki.gnome.org/Projects/NetworkManager
net_applet is our default applet, which usually gives more trouble then network manager, and in all cases where I recommended network manager instead of net_applet it usually fixed the issues people had before. Hence the link to https://forums.mageia.org/en/viewtopic.php?f=25&t=5782 in comment 15.

# echo "blacklist dell_wmi" > /etc/modprobe.d/blacklist-dell.conf

 does the  same as in Comment 18: reboot with wifi, shots it down after lid closes. I'll attach  journal -ab with my best guess about time.

Created attachment 7487 [details]
no wifi at the end

Network Manager and net_applet look very different from developer point of view (yours) and users one (mine). 

GNOME setting has Network, MCC has Network Center that looks like drakconnect at some point. 

Wiki Network Manager talks about package and forum conversation is too technical too. I'll post pictures just incase.

Created attachment 7488 [details]
Gnome setting - Network

Created attachment 7489 [details]
MCC Network Center

Created attachment 7490 [details]
# drakconnect

(In reply to Palm Pre from comment #24)
> Network Manager and net_applet look very different from developer point of
> view (yours) and users one (mine). 
> GNOME setting has Network, MCC has Network Center that looks like
> drakconnect at some point. 

I'm also just a simple user who wants a simple applet to manage e.g. wireless connections. And I switched from net_applet (which you currently use) to networkmanager simply because it gives less issues.

net_applet and nm-applet are applets that offer the same function and that look pretty similar. For nm-applet see https://fedoraproject.org/wiki/NetworkManager_in_Fedora_13

> Wiki Network Manager talks about package and forum conversation is too
> technical too. I'll post pictures just incase.

Not sure what those screenshots are intended for.

Do you want working wifi or not?

Those screenshots show there are no Network Manager or net_applet in GNOME installations. 

It looks like you are calling something I'm using by different names and I want to make sure I understand what you are talking about.

How can I make it work if I don't see any item you're mentioning. But I see three more items on my desktop you never mentioned and they should work.

(In reply to Marja van Waes from comment #10)
> @ Palm Pre
> 
> Can you try whether after reopening the lid, doing (as root)
> 
>   systemctl restart network.service 
> 
> correctly enables your wlan connection again?
> 
> 

Still curious about the answer. If it gets it working again, then you have a faster way then re-running drakconnect. You can give a short alias to the command.

Yeah, match shorter command. How to make that alias?

I'm getting similar symptoms to the reported problems here on my Acer laptop with Mageia v5 x86-64. After I run "pm-suspend" and turn on the laptop, then the wifi is off, and "service network restart" will not start it again.

My computer's specs are:

<<<
 I also have an Acer Aspire 5738DZG laptop with the following specs:

    Intel Pentium(R) Dual-Core CPU T4300 @ 2.10GHz. (x86-64).
    ATI Mobility Radeon⢠HD 4570 (r700)
    15.6â³ 3D HD LCD Screen.
    3 GB Memory
    320 GB Hard Disk Drive.
    âDVD Super Multi DL driveâ
    Acer Nplify⢠802.11b/g/n.

>>>

CC: (none) => shlomif

(In reply to Palm Pre from comment #31)
> Yeah, match shorter command. How to make that alias?

For instance by adding the following lines to the end of /root/.bashrc

    # easier restart of network

    alias renet='systemctl restart network.service'

You can then type "renet" as root to restart the network.

However, if  the long command didn't bring up the network correctly (what happened when you tried? You didn't tell), then the alias won't help, either.

(Btw, the command Shlomi used, "service network restart" invokes restarting it via systemctl nowadays, so should work just as good or bad)

Is this bug still valid?

Still using # systemctl restart network.service on old laptop. Sometimes I need to use it twice for wi-fi restart.

I have different laptop with Broadcom wi-fi chipset (BCM4313) and the same story - you need to issue "# systemctl restart network.service" and hit Enter key at least twice to restart service. 

# systemctl restart network.service
Job for network.service failed because the control process exited with error code.
See "systemctl status network.service" and "journalctl -xe" for details.

Btw, #drakconnect gives this at the very beginning

Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.22.3/Gtk3.pm line 525.

OK can we have another go at this.

I have access to two laptops both of which have:
Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
(both same rev 02)

One works perfectly in that the wifi is restored when coming out of suspend ALWAYS.

The other ALWAYS fails to reconnect wifi on resume.

Both are Acer laptops of similar age with Intel processors and both are running fully updated Mageia 6

I have tried everything suggested in this bug including switching to NetworkManager, adding the blacklist for acer_wmi (although this is not blacklisted on the working machine). Restarting network service after resume fails to reconnect.
Attaching journal output while attempting to do this below.

The one thing that IS different between these machines is the graphic cards.
The working one has on-board Intel graphics whereas the failing one has NVIDIA card:
VGA compatible controller: NVIDIA Corporation G86M [GeForce 8600M GS] (rev a1)

Does any of the above prompt any thoughts on how to solve this?

Version: 5 => 6
CC: (none) => zen25000

Created attachment 9909 [details]
journal output

This journal output starts after the machine has come out of resume after being suspended from a working state with wifi connected.

I then log in as root and run systemctl restart network.

Created attachment 9910 [details]
journal through suspend and restore

This may give more clues.
I started journalctl -f before going into suspend and stopped it after resume.

I finally changed the wifi card to a broadcom and after installing the correct firmware the wifi is instantly restored after suspend. I am still using NetworkManager.

I then discovered that closing the lid put the machine into some other state than suspend, which could not be resumed. systemsettings power management settings were correct.

This fixed the lid issue:

https://askubuntu.com/questions/767911/how-to-get-laptop-lid-to-suspend-resume-and-wifi-to-reconnect-with-ubuntu-16

Now closing the lid goes into suspend and opening the lid restores correctly with wi-fi working.

This bug report is not yet fixed, but the above may help someone in the same situation.

Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan 
to fix it in a currently maintained version, simply change the 'version' to 
a later Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we 
weren't able to fix it before Mageia 6's end of life. If you are able to 
reproduce it against a later version of Mageia, you are encouraged to click 
on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a more recent
Mageia release includes newer upstream software that fixes bugs or makes them
obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Best regards,
Aurélien
Bugsquad Team

CC: (none) => ouaurelien

Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan 
to fix it in a currently maintained version, simply change the 'version' to 
a later Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we 
weren't able to fix it before Mageia 6's end of life. If you are able to 
reproduce it against a later version of Mageia, you are encouraged to click 
on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a more recent
Mageia release includes newer upstream software that fixes bugs or makes them
obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Best regards,
Aurélien
Bugsquad Team

Resolution: (none) => OLD
Status: NEW => RESOLVED