Bug 1167455

Sorry, it seems like I cut off various places of messages and dmesg, because there are many AP around with the same SSID (eduroam) and the system was trying to connect any possible reachable AP.

What wireless chipset and driver is in use here?

This is HP ProBook 450 G2 with Intel Core i5, the wireless card is:

lspci:
09:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter

lspci -nvvv:
09:00.0 0280: 10ec:b723
	DeviceName: WLAN
	Subsystem: 103c:2231
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 19
	Region 0: I/O ports at 4000 [size=256]
	Region 2: Memory at d0500000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: rtl8723be
	Kernel modules: rtl8723be

Today I found, that with older kernel, the situaton is the same (ie too short timeoutn probably?). After a while on the network, when reconnection occured it was not possible to reconnect. I tryed to unload/reload the rtl8723be module with no luck.

The situation persis when I moved to another WiFi (ie. from eduroam with Cisco APs to the home WiFi with WPA2/PSK with Mikrotik). The delay between three "direct probe" is 0.2 sec according the dmesg output.

Probably I have to rebot or reload other modules for WiFi. Any ideas? Suggestions? Which module I sould istruct to produce debug messages?

Unsuccesfull association to Cisco AP with eduroam Wi-Fi:
[66286.273165] wlo1: authenticate with 00:23:04:88:da:e0
[66290.486004] wlo1: direct probe to 00:23:04:88:da:e0 (try 1/3)
[66290.686919] wlo1: direct probe to 00:23:04:88:da:e0 (try 2/3)
[66290.888075] wlo1: direct probe to 00:23:04:88:da:e0 (try 3/3)
[66291.089281] wlo1: authentication with 00:23:04:88:da:e0 timed out
[66304.625720] wlo1: authenticate with 00:23:04:88:da:10
[66308.848646] wlo1: direct probe to 00:23:04:88:da:10 (try 1/3)
[66309.049592] wlo1: direct probe to 00:23:04:88:da:10 (try 2/3)
[66309.250750] wlo1: direct probe to 00:23:04:88:da:10 (try 3/3)
[66309.451890] wlo1: authentication with 00:23:04:88:da:10 timed out
[66322.248681] wlo1: authenticate with 00:23:04:88:c1:e0
[66326.471810] wlo1: direct probe to 00:23:04:88:c1:e0 (try 1/3)
[66326.672714] wlo1: direct probe to 00:23:04:88:c1:e0 (try 2/3)
[66326.873947] wlo1: direct probe to 00:23:04:88:c1:e0 (try 3/3)
[66327.075088] wlo1: authentication with 00:23:04:88:c1:e0 timed out

Unsuccesfull and the succesfull association at home (no deleted lines):
[66424.074991] wlo1: authenticate with 38:72:c0:0a:86:ff
[66424.085196] wlo1: direct probe to 38:72:c0:0a:86:ff (try 1/3)
[66424.285679] wlo1: direct probe to 38:72:c0:0a:86:ff (try 2/3)
[66424.486868] wlo1: direct probe to 38:72:c0:0a:86:ff (try 3/3)
[66424.688014] wlo1: authentication with 38:72:c0:0a:86:ff timed out
[66435.630257] wlo1: authenticate with 38:72:c0:0a:86:ff
[66435.640450] wlo1: direct probe to 38:72:c0:0a:86:ff (try 1/3)
[66435.840929] wlo1: direct probe to 38:72:c0:0a:86:ff (try 2/3)
[66436.042112] wlo1: direct probe to 38:72:c0:0a:86:ff (try 3/3)
[66436.243267] wlo1: authentication with 38:72:c0:0a:86:ff timed out
[66682.640616] rtl8723be: Using firmware rtlwifi/rtl8723befw.bin
[66682.641196] ieee80211 phy3: Selected rate control algorithm 'rtl_rc'
[66682.641646] rtlwifi: wireless switch is on
[66682.650239] rtl8723be 0000:09:00.0 wlo1: renamed from wlan0
[66683.139431] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready
[66705.233929] wlo1: authenticate with 38:72:c0:0a:86:ff
[66705.254004] wlo1: send auth to 38:72:c0:0a:86:ff (try 1/3)
[66705.255563] wlo1: authenticated
[66705.256556] wlo1: associate with 38:72:c0:0a:86:ff (try 1/3)
[66705.259478] wlo1: RX AssocResp from 38:72:c0:0a:86:ff (capab=0x411 status=0 aid=5)
[66705.259609] wlo1: associated
[66705.259617] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready

The problem is the same with kernel-3.17.4-300.fc21.x86_64. Did not try today's 301 version.
I'm still unable to connect to 802.1X Wi-Fi network at the university campus (eduroam). The APs are Cisco routers. Reboot did not help. Classic WPA/PSK network at home (Mikrotik AP) works.
After reboot to the older kernel-3.17.2-300.fc21.x86_64 it connect to the network immediately.
If you wrote what I have to try to help you debug this, I will try it the same evening (I live in the central Europe - CET timezone).

Were there any changes in drivers rtlwifi, rtl_pci or rtl8723be between 3.17.2 and 3.17.4? I am not aware of any.

If there is a test kernel for 3.18-rc6 or -rc7, please try it. There have been a lot of changes to the entire rtlwifi family.

I have the same issue after upgrading from F20 to F21 using the Intels Cetrino Advanced-N card and the latest kernel.

uname -a
Linux chronic 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

My wireless card info:

25:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)


lsmod |grep wl
iwldvm 245252 0 
mac80211 650374 1 iwldvm
iwlwifi 129618 1 iwldvm
cfg80211 505401 3 iwlwifi,mac80211,iwldvm


dmesg says that it gets authenticated:
[ 1765.729935] wlo1: aborting authentication with c8:d7:19:b5:9f:a2 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 1780.758628] wlo1: authenticate with c8:d7:19:b5:9f:a3
[ 1780.762213] wlo1: send auth to c8:d7:19:b5:9f:a3 (try 1/3)
[ 1780.768339] wlo1: authenticated


I'm trying to connect to a WPA2 configured router. I also tried with a security disabled network and still no luck.


I've also tried the "options iwlwifi 11n_disable=1" settings but it's still the same

I did: yum --enablerepo=updates-testing update kernel

Now on 3.18.2-200.fc21 (uname -r) and this is much better - I'm able to connect like before.
The only problem is that after a while, the connection is still up, but no data are passing through and I have to reconnect to the wireless network (in my case, this is 802.1X authentization vie Radius server - like "eduroam" has).

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.18.3-201.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

I can confirm that this bug is still happening to me on version 3.17.8.300.fc21.x86-64

However, as a bit of additional information, the wifi seems to work perfectly if I connect a wired network connection.  I don't have to be using the wired connection, it just has to be plugged in - it doesn't even have to have an IP address.

I'm running the kernel update from testing now.  I'll report back after that is complete.

I just ran : yum --enablerepo=updates-testing update kernel
and that updated me to : 3.18.6-200.fc21.x86_64

A quick check showed that I was able to connect to the wifi network with no issues.  I will need a longer test to make sure that it stays connected and that performance remains consistent.  This is certainly an improvement.

Short version: Kernel update helps (maybe solves) this bug for me.

(In reply to Adrian Dinita from comment #8)
> I have the same issue after upgrading from F20 to F21 using the Intels
> Cetrino Advanced-N card and the latest kernel.
> 
> uname -a
> Linux chronic 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> 
> My wireless card info:
> 
> 25:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
> [Taylor Peak] (rev 34)
> 
> 
> lsmod |grep wl
> iwldvm 245252 0 
> mac80211 650374 1 iwldvm
> iwlwifi 129618 1 iwldvm
> cfg80211 505401 3 iwlwifi,mac80211,iwldvm
> 
> 
> dmesg says that it gets authenticated:
> [ 1765.729935] wlo1: aborting authentication with c8:d7:19:b5:9f:a2 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [ 1780.758628] wlo1: authenticate with c8:d7:19:b5:9f:a3
> [ 1780.762213] wlo1: send auth to c8:d7:19:b5:9f:a3 (try 1/3)
> [ 1780.768339] wlo1: authenticated
> 
> 
> I'm trying to connect to a WPA2 configured router. I also tried with a
> security disabled network and still no luck.
> 
> 
> I've also tried the "options iwlwifi 11n_disable=1" settings but it's still
> the same

Hi Adrian,

While your symptoms look similar, the fact that the underlying chipset (you have Intel) is totally different *may* cause your issue to go into a black hole needlessly here.  I'd suggest you open your own bug with this comment and we'll handle your case more specifically if the new kernel here doesn't work for you.

Sorry for the hassle..trying to get you help quickly.

(In reply to John Greene from comment #13)
> (In reply to Adrian Dinita from comment #8)
> > I have the same issue after upgrading from F20 to F21 using the Intels
> > Cetrino Advanced-N card and the latest kernel.
> > 
> > uname -a
> > Linux chronic 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014
> > x86_64 x86_64 x86_64 GNU/Linux
> > 
> > My wireless card info:
> > 
> > 25:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
> > [Taylor Peak] (rev 34)
> > 
> > 
> > lsmod |grep wl
> > iwldvm 245252 0 
> > mac80211 650374 1 iwldvm
> > iwlwifi 129618 1 iwldvm
> > cfg80211 505401 3 iwlwifi,mac80211,iwldvm
> > 
> > 
> > dmesg says that it gets authenticated:
> > [ 1765.729935] wlo1: aborting authentication with c8:d7:19:b5:9f:a2 by local
> > choice (Reason: 3=DEAUTH_LEAVING)
> > [ 1780.758628] wlo1: authenticate with c8:d7:19:b5:9f:a3
> > [ 1780.762213] wlo1: send auth to c8:d7:19:b5:9f:a3 (try 1/3)
> > [ 1780.768339] wlo1: authenticated
> > 
> > 
> > I'm trying to connect to a WPA2 configured router. I also tried with a
> > security disabled network and still no luck.
> > 
> > 
> > I've also tried the "options iwlwifi 11n_disable=1" settings but it's still
> > the same
> 
> Hi Adrian,
> 
> While your symptoms look similar, the fact that the underlying chipset (you
> have Intel) is totally different *may* cause your issue to go into a black
> hole needlessly here.  I'd suggest you open your own bug with this comment
> and we'll handle your case more specifically if the new kernel here doesn't
> work for you.
> 
> Sorry for the hassle..trying to get you help quickly.

That's not a bad idea, John.  But I actually have an Intel chip as well.  I hadn't noticed the Realtek part of this bug report as I was searching on my phone.  So - at least for me - this same kernel update fixed Intel.

With the kernel 3.18.5-201.fc21.x86_64 I'm able to connect to any WiFi network I tried without issues (home networks with WPA/PSK, school network with 802.1X and Radius), so this kernel fixes the primary problem I had here.

But after a while, the connection stops transmitting with no lines in dmesg output (I have no special options for rtl8723be module). I have to reconnect to allow data to go through. The problem is not related to the network or device I'm connected to (Comtrend DSL modem, Mikrotik, Cisco AP).

Some users report more success when using the option "ips=0" when loading driver rtl8723be. Kernel 3.18 is definitely better than 3.17.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.19.5-200.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22.

If you experience different issues, please open a new bug report for those.

(In reply to Milan Kerslager from comment #15)
> With the kernel 3.18.5-201.fc21.x86_64 I'm able to connect to any WiFi
> network I tried without issues (home networks with WPA/PSK, school network
> with 802.1X and Radius), so this kernel fixes the primary problem I had here.
> 
> But after a while, the connection stops transmitting with no lines in dmesg
> output (I have no special options for rtl8723be module). I have to reconnect
> to allow data to go through. The problem is not related to the network or
> device I'm connected to (Comtrend DSL modem, Mikrotik, Cisco AP).

Is this still an issue Milan?

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

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 Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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 Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

No info needed anymore.