Created attachment 5386 [details]
journalctl -f when removing and re-adding the wlan adapter in MCC

After removing and re-adding the WLAN adapter in MCC, the WLAN connection still didn't work (the connection that does work in that log is the LAN one. At the end, draknetcenter showed wlan was still down)

For the record: another laptop doesn't have a problem connecting to the same access point

Can you attach full dmesg or journalctl -b

so I can see wich fw it triggerss

Created attachment 5387 [details]
journalctl -b

(In reply to Thomas Backlund from comment #3)
> Can you attach full dmesg or journalctl -b
> 
> so I can see wich fw it triggerss


Attaching :-)

Hm, that fw did not change :/...

Oh wait... could it be possible you got the initscript update at the same time ?

Created attachment 5388 [details]
updates of 2014-08-30 22:19h CEST

(In reply to Thomas Backlund from comment #5)
> Hm, that fw did not change :/...
> 
> Oh wait... could it be possible you got the initscript update at the same
> time ?

Yes, I hadn't noticed that at all, only saw it was already updated when I was amazed that I didn't get it together with the systemd update today.

I'll attach the cli output of what got updated at the same time as iwlwifi-agn-ucode

Adding Colin in cc


if you remove all references to the wlan interface in mcc, reboot, and try to configure it with networkmanager, does it make any difference ?

CC: (none) => mageia

(In reply to Thomas Backlund from comment #7)
> Adding Colin in cc
> 
> 
> if you remove all references to the wlan interface in mcc, reboot, and try
> to configure it with networkmanager, does it make any difference ?

It worked very shortly, but maybe I didn't exactly do what you asked me:

After removing the connection and rebooting, I installed networkmanager and did 
systemctl enable NetworkManager.service
then I configured the interface again over MCC, and set it to allow it to be controlled by NetworkManager.

It worked shortly, and then stopped. Trying to start it again doesn't work.
I'll remove the connection again, and remove drakx-net* with "rpm -e --nodeps" before rebooting and trying whether I can configure it with networkmanager-applet in KDE

Btw, I also tried the initscripts-9.55-2.mga5 Luc pushed today (without networkmanager), but that didn't make a difference

s/without/before trying/

Nice, there is plasma-applet-nm for KDE :-)

networkmanager seems to work well and keep working, after removing all *drakx-net* packages.

Thanks for suggesting this, Thomas

Created attachment 5389 [details]
journalctl -f of 2x trying to connect with draknetcenter

hmm, another cauldron, which at first did not have any WLAN problems after getting those updates and rebooting, does now have them (since, late yesterday, I stopped the external one to test whether the internal one worked better than before, and after that tried to connect the internal one to the best access point instead of to the 2nd best)

I have the feeling the cause is the same, even if this is about different networkcards, so for now I'll add the details here instead of in a separate bug report.

(Of course draknetcenter crashes, but it already used to do that before, bug 12861 - the drakbug backtrace is the same - without hindering the connection.)

attaching journalctl -f of when trying to connect over draknetcenter with both wlan adapters, one after the other.
Here, too, there is "link beat not detected"

The adapters are:

rtl8192ce       : Realtek Semiconductor Co., Ltd.|RTL8188CE 802.11b/g/n WiFi Adapter [NETWORK_OTHER] (vendor:10ec device:8176 subv:10ec subd:8195) (rev: 01)
and
rt2800usb       : Ralink|802.11 n WLAN (vendor:7392 device:7711)

cc'ing blino and tv, I'll later attach journalctl -a of yesterday (from when I got those updates till after I stopped one wlan adapter and tried to reconnect the other to a different WAP)

CC: (none) => mageia, thierry.vignaud

As mentioned on the Cauldron mailing list before pushing initscripts on Saturday, it's almost certainly the changes made there that caused this regression. I somewhat predicted that the change to using a different set of tools and with relatively minimal support would have caused this.

I'll setup my old laptop tonight and try and debug it further.

Anyway, not at all unexpected as I mentioned in my warning on the ML!!

(In reply to Colin Guthrie from comment #13)
> As mentioned on the Cauldron mailing list before pushing initscripts on
> Saturday, it's almost certainly the changes made there that caused this
> regression. I somewhat predicted that the change to using a different set of
> tools and with relatively minimal support would have caused this.
> 
> I'll setup my old laptop tonight and try and debug it further.
> 
> Anyway, not at all unexpected as I mentioned in my warning on the ML!!

Thanks for confirming it is initscripts that caused this.

Do you need more information of me? (That journalctl -a of yesterday greatly confuses me, so if you don't need it I'll stop wondering when I did what, and why what happens)

Created attachment 5391 [details]
journalctl -xn

Should have looked at this before, of course:

  network-up.service                                                        loaded    inactive dead      LSB: Wait for the hotplugged network to be up
â network.service                                                           loaded    failed   failed    LSB: Bring up/down networking


starting network-up.service works fine, but starting network.service doesn't (I didn't attach the 2nd wlan adapter, but can't imagine that would have made a difference)

I'll attach the "journalctl -xn" output

(This is on a laptop where I didn't switch to NetworkManager)

There is usually more output from the network service than that. Perhaps "journalctl -xb -u network" output would be more useful (-n truncates it to 10 lines)?

Anyway, I'm sure even that won't tell me enough unless I enable "set -x" in the networking scripts (probably in the "/etc/sysconfig/network-scripts/ifup" script)

I'm sure I'll be able to reproduce on my old laptop but sadly didn't have time last night :( Will try again tonight!

Created attachment 5392 [details]
journalct -xb -u network

attaching it anyway, just in case :-)

please ignore the "Bringing up interface wlp0s20u2:  ERROR", that wlan-adapter wasn't plugged in.

I've abandoned all hope of bringing our legacy networking stuff up to speed for now so just reverted back to our old scripts for now. It should be OK again, but just continues to be rather fragile!

(In reply to Colin Guthrie from comment #18)
> I've abandoned all hope of bringing our legacy networking stuff up to speed
> for now so just reverted back to our old scripts for now. It should be OK
> again, but just continues to be rather fragile!

Sorry, didn't find time to go back from networkmanager to drakx-net, so didn't check, but I'm sure it'll be OK.

So closing as fixed

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