Bug 729618 - rtl8192ce reloads firmware all the time
Summary: rtl8192ce reloads firmware all the time
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-10 11:43 UTC by Stefan Assmann
Modified: 2012-02-23 08:19 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-23 08:19:10 UTC


Attachments (Terms of Use)
dmesg.txt (74.82 KB, text/plain)
2011-08-12 17:53 UTC, Stefan Assmann
no flags Details
Test patch for firmware reload issue (808 bytes, patch)
2011-08-12 19:35 UTC, Larry Finger
no flags Details | Diff
Patch to implement global debugging (1.25 KB, application/octet-stream)
2011-08-13 16:09 UTC, Larry Finger
no flags Details
dmesg-debug.txt (124.18 KB, text/plain)
2011-08-15 07:44 UTC, Stefan Assmann
no flags Details
latest rtl819x linux driver (4.50 MB, application/x-gzip-compressed)
2011-08-19 02:54 UTC, chaoming_li
no flags Details
Patch needed to compile Realtek driver on latest kernels (2.50 KB, patch)
2011-08-19 04:07 UTC, Larry Finger
no flags Details | Diff
dmesg-newdriver.txt (74.71 KB, text/plain)
2011-08-19 09:17 UTC, Stefan Assmann
no flags Details
dmesg-new.txt (121.91 KB, text/plain)
2011-08-22 09:58 UTC, Stefan Assmann
no flags Details
dmesg-nolps.txt (122.87 KB, text/plain)
2011-08-24 09:35 UTC, Stefan Assmann
no flags Details
dmesg-conloss.txt (123.13 KB, text/plain)
2011-08-25 12:37 UTC, Stefan Assmann
no flags Details
dmesg-connection-loss-commented-out.txt (106.76 KB, text/plain)
2011-10-14 10:38 UTC, Stefan Assmann
no flags Details
beacons.txt (335.03 KB, text/plain)
2011-10-17 15:18 UTC, Stefan Assmann
no flags Details
mac80211_offchannel_rework_revert_v2.patch (21.31 KB, text/plain)
2011-11-29 09:24 UTC, Stanislaw Gruszka
no flags Details
dmesg 2.6.41.5-1.fc15.x86_64 (8.14 KB, text/plain)
2011-12-14 19:50 UTC, Bill McGonigle
no flags Details
kickstart file (3.64 KB, text/plain)
2012-01-01 21:50 UTC, W Agtail
no flags Details
/etc/sysconfig/network-scripts (32 bytes, text/plain)
2012-01-01 21:51 UTC, W Agtail
no flags Details
/etc/sysconfig/network-scripts (306 bytes, text/plain)
2012-01-01 21:52 UTC, W Agtail
no flags Details
output from 'iwconfig wlan0' (486 bytes, text/plain)
2012-01-01 21:53 UTC, W Agtail
no flags Details
kickstart file ks.cfg (3.67 KB, text/plain)
2012-01-01 22:03 UTC, W Agtail
no flags Details
messages (1.21 MB, text/plain)
2012-01-02 04:41 UTC, W Agtail
no flags Details
wpa_supplicant.log (854.22 KB, text/plain)
2012-01-02 04:42 UTC, W Agtail
no flags Details

Description Stefan Assmann 2011-08-10 11:43:41 UTC
Description of problem:
The wireless wrtl8192ce driver seems to randomly reload firmware and cuts connection.
01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. Device [10ec:8176] (rev 01)

Note the following dmesg was captured while the driver was not even connected to an AP.
[ 9829.009015] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 9949.009015] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10069.003007] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10189.004397] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10309.008018] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10429.006391] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10549.008295] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10669.006024] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10789.008013] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[10909.008018] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11029.006018] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11149.010019] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11269.007016] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11389.008011] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11509.008014] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11629.009005] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11749.008015] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11869.008014] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[11989.008020] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[12109.008015] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[12229.011025] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin
[12349.011020] rtl8192c: Loading firmware file rtlwifi/rtl8192cfw.bin


Version-Release number of selected component (if applicable):
kernel-2.6.40-4.fc15.x86_64

How reproducible:
always

Comment 1 Stanislaw Gruszka 2011-08-12 13:45:16 UTC
Hi Stefan, did you report this problem to Larry Finger?

Comment 2 Stefan Assmann 2011-08-12 13:51:12 UTC
Not yet since I'm not really sure what's going on. Could it be that userspace is acting up? If you think I should contact Larry I will do so.

Comment 3 Stanislaw Gruszka 2011-08-12 14:09:08 UTC
Yes. Maybe this is known problem. Otherwise some debugging will be needed - perhaps Larry would like to dig into it.

Comment 4 Stanislaw Gruszka 2011-08-12 14:10:35 UTC
(In reply to comment #1)
> Hi Stefan, did you report this problem to Larry Finger?

Oh, he's CC'ed :-/

Comment 5 Larry Finger 2011-08-12 15:34:56 UTC
I am not a Fedora user. What is kernel 2.6.40-4 in terms of what I know?

I have not seen this problem before.

Is this a pre-built kernel, or do you build your own? If the latter, go to drivers/net/wireless/rtlwifi/debug.c and find the line that says

        rtlpriv->dbg.global_debuglevel = DBG_EMERG;

Change the DBG_EMERG to DBG_DMESG, run the driver, and attach the dmesg output to this bug report. That should tell us why the firmware is being reloaded. My TODO list includes an item to make this quantity be a module parameter, but I have not yet done that.

If you use a pre-built kernel, please get the latest compat-wireless sources, make the above change, and build a new version. You will need the kernel headers installed. Someone else will need to advise you on the necessary packages.

Comment 6 Stefan Assmann 2011-08-12 15:44:07 UTC
(In reply to comment #5)
> I am not a Fedora user. What is kernel 2.6.40-4 in terms of what I know?

That's a 3.0 kernel. :)

> 
> I have not seen this problem before.
> 
> Is this a pre-built kernel, or do you build your own? If the latter, go to
> drivers/net/wireless/rtlwifi/debug.c and find the line that says

It's the latest shipping kernel, but I can compile a 3.0 vanilla with the change below.

> 
>         rtlpriv->dbg.global_debuglevel = DBG_EMERG;
> 
> Change the DBG_EMERG to DBG_DMESG, run the driver, and attach the dmesg output
> to this bug report. That should tell us why the firmware is being reloaded. My
> TODO list includes an item to make this quantity be a module parameter, but I
> have not yet done that.
> 
> If you use a pre-built kernel, please get the latest compat-wireless sources,
> make the above change, and build a new version. You will need the kernel
> headers installed. Someone else will need to advise you on the necessary
> packages.

Not an issue, I know my way around. I'll report back, thanks Larry.

Comment 7 Stefan Assmann 2011-08-12 17:53:58 UTC
Created attachment 518076 [details]
dmesg.txt

Probably a power management issue? But PM seems to be turned off
iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:off

Comment 8 Larry Finger 2011-08-12 19:35:10 UTC
Created attachment 518098 [details]
Test patch for firmware reload issue

Check if this patch helps. For a number of reasons, I'm afraid of side effects from this, but at least see if it helps your case. You can remove the extra debug output now. It did it's job.

Larry

Comment 9 Stefan Assmann 2011-08-13 11:46:38 UTC
I'm pretty sure your patch suppressed the dmesg output, but I'm also seeing a short network disconnect (packet loss) whenever the firmware is reloaded. So the problem has to be somewhere else.
Btw, I'm on 3.1-rc1 now, same issue.

Comment 10 Larry Finger 2011-08-13 15:45:33 UTC
No, the patch did more than suppress the dmesg output. It completely skipped the firmware reload. Yes, the problem is somewhere else, but not in this routine.

What tests do you do to detect this packet loss?

I will be posting a patch to let us dynamically change the debug level. Perhaps that will let us find the problem.

Comment 11 Larry Finger 2011-08-13 16:09:22 UTC
Created attachment 518154 [details]
Patch to implement global debugging

After this patch is installed, unload rtl8192ce and reload as follows:

modprobe -v rtlwifi debug=4
modprobe -v rtl8192ce

You will get additional debug info in the logs.

Comment 12 Stefan Assmann 2011-08-15 07:44:23 UTC
Created attachment 518231 [details]
dmesg-debug.txt

Here's your log.
I tracked the issue by running ping <AP> in a terminal and that shows dropped packages. Also I first discovered the issue because my connection to the AP drops occasionally and everytime that happens the firmware reload message is printed.

Comment 13 Larry Finger 2011-08-18 15:03:21 UTC
The patch should have gotten rid of the firmware reload messages.

Your dmesg output shows the following error:

[   48.767659] rtl8192c_common:_rtl92c_fill_h2c_command():<100-1> Wating too long for FW read clear HMEBox(0)!
[   48.767659] rtl8192c_common:_rtl92c_fill_h2c_command():<100-1> Write H2C register BOX[0] fail!!!!! Fw do not read.

This may be a failure in the device or incorrect firmware. Please compare the md5sum of the firmware file to mine:

748944fbffd3b08b5b1929bb6c7fc537  /lib/firmware/rtlwifi/rtl8192cfw.bin

I will alert my contact at Realtek and have him review this thread and look at your dmesg output.

Comment 14 Stefan Assmann 2011-08-18 15:30:27 UTC
Looks identical
md5sum /lib/firmware/rtlwifi/rtl8192cfw.bin 
748944fbffd3b08b5b1929bb6c7fc537  /lib/firmware/rtlwifi/rtl8192cfw.bin

Comment 15 Larry Finger 2011-08-18 17:22:08 UTC
OK, we can rule out faulty firmware.

While we are waiting for the Realtek engineers to look at the material, please try turning off power save.

sudo modprobe -rv rtl8192ce
sudo modprobe -v rtl8192ce ips=0

I'm currently reworking the module options, but you don't need the patch to test.

Comment 16 chaoming_li 2011-08-19 02:50:00 UTC
Dear all:

1. about "Loading firmware file rtlwifi/rtl8192cfw.bin" issue.
   It just happened when wifi not connected to AP, right ?
   If yes, I think it's a normal message when you open inactiveps like follwing code:

   static struct rtl_mod_params rtl92ce_mod_params = {
	.sw_crypto = false,
	.inactiveps = true,
	.swctrl_lps = false,
	.fwctrl_lps = true,
   };

   because Drier will disable hardware when there's no link or other works like scan. but when you or network ask driver to scan, driver will reenable hardware, this will cause firmware loading again.


2. about the "Wating too long for FW read clear HMEBox(0)!" issue, can you test our released driver in the attachment, because I can not reproduce this issue on my platform.

Thank you!
chaoming_li

Comment 17 chaoming_li 2011-08-19 02:54:37 UTC
Created attachment 518968 [details]
latest rtl819x linux driver

latest rtl8188ce driver

Comment 18 Larry Finger 2011-08-19 04:07:29 UTC
Created attachment 518970 [details]
Patch needed to compile Realtek driver on latest kernels

Comment 19 Stefan Assmann 2011-08-19 08:26:21 UTC
(In reply to comment #16)
> Dear all:
> 
> 1. about "Loading firmware file rtlwifi/rtl8192cfw.bin" issue.
>    It just happened when wifi not connected to AP, right ?

No it also happens if wifi is connected, followed by a network manager disconnect and reconnect.

> 2. about the "Wating too long for FW read clear HMEBox(0)!" issue, can you test
> our released driver in the attachment, because I can not reproduce this issue
> on my platform.

I will do so. Thanks!

Comment 20 Stefan Assmann 2011-08-19 09:17:05 UTC
Created attachment 518997 [details]
dmesg-newdriver.txt

From a quick run of about half an hour I did not see any ping packets being dropped or any messages about firmware reloading. However I still get a lot of disconnects, reconnects by Network Manager. See dmesg.

Comment 21 chaoming_li 2011-08-19 09:28:20 UTC
(In reply to comment #19)
> (In reply to comment #16)
> > Dear all:
> > 
> > 1. about "Loading firmware file rtlwifi/rtl8192cfw.bin" issue.
> >    It just happened when wifi not connected to AP, right ?
> No it also happens if wifi is connected, followed by a network manager
> disconnect and reconnect.

  Yes, it just when disconnect and before connect again.

> > 2. about the "Wating too long for FW read clear HMEBox(0)!" issue, can you test
> > our released driver in the attachment, because I can not reproduce this issue
> > on my platform.
> I will do so. Thanks!

Comment 22 chaoming_li 2011-08-19 09:30:55 UTC
(In reply to comment #20)
> Created attachment 518997 [details]
> dmesg-newdriver.txt
> From a quick run of about half an hour I did not see any ping packets being
> dropped or any messages about firmware reloading. However I still get a lot of
> disconnects, reconnects by Network Manager. See dmesg.

From dmesg I found that, there's something wrong with your AP, it always 
not send a beacon within 2s, our driver will think AP is power off and disconnect it. So can you reboot AP and try again.

Thank you!
chaoming_li

Comment 23 Stefan Assmann 2011-08-19 10:22:30 UTC
(In reply to comment #22)
> From dmesg I found that, there's something wrong with your AP, it always 
> not send a beacon within 2s, our driver will think AP is power off and
> disconnect it. So can you reboot AP and try again.

Beacon Interval is set to 100ms on my AP and actually non of my other systems using iwlagn, ipw2200 and r8712u complain or disconnect from the AP. I even put my notebook next to the AP and it still disconnects, so it's also not range issue.
Thanks for looking into it!

Comment 24 Stefan Assmann 2011-08-19 10:44:36 UTC
Actually there are a few packets dropped, but I guess that comes with the disconnect.
777 packets transmitted, 771 received, 0% packet loss, time 777322ms
rtt min/avg/max/mdev = 1.136/6.078/522.238/28.489 ms

Comment 25 Larry Finger 2011-08-19 15:09:38 UTC
It seems that the updated driver helped.

Even though the beacon interval is 100ms, the RTL8188CE is not seeing the beacons for 2s. Either the AP is not sending them, or the RTL8188CE is not seeing them. Rebooting the AP should help sort out which is happening.

I am reviewing the changes between the current version of rtl8192ce in the kernel and the driver that Chaoming posted here. I will prepare a patch to incorporate the important parts for testing.

Comment 26 Stefan Assmann 2011-08-19 15:17:11 UTC
Thanks Larry,
I rebooted the AP twice and still see the disconnects (on this device only).

Comment 27 chaoming_li 2011-08-22 01:24:49 UTC
Dear Stefan Assmann:

   Can you set rtlpriv->dbg.global_debuglevel = DBG_DMESG; in rtl_dbgp_flag_init, and give me dmesg after disconnect.
   And can you tell me your AP's model and configration.

Thank you!
chaoming_li

Comment 28 Stefan Assmann 2011-08-22 09:58:52 UTC
Created attachment 519255 [details]
dmesg-new.txt

Hi Chaoming_li,
here's the dmesg output with debug enabled.
My AP is a D-Link DIR-825 running dd-wrt.

Comment 29 chaoming_li 2011-08-24 01:05:32 UTC
Dear Stefan Assmann:

Can you try to close fwctrl_lps by set fwctrl_lps = false like follwing, and test again.

   static struct rtl_mod_params rtl92ce_mod_params = {
      .sw_crypto = false,
      .inactiveps = true,
      .swctrl_lps = false,
      .fwctrl_lps = false,
   };


Thank you!
lizhaoming

Comment 30 Stefan Assmann 2011-08-24 09:35:11 UTC
Created attachment 519579 [details]
dmesg-nolps.txt

Still the same. Here's the dmesg output with debug enabled.

Comment 31 chaoming_li 2011-08-24 09:53:19 UTC
(In reply to comment #30)
> Created attachment 519579 [details]
> dmesg-nolps.txt
> Still the same. Here's the dmesg output with debug enabled.

Can you help to mark ieee80211_connection_loss(rtlpriv->mac80211.vif);
in base.c like this:

    //ieee80211_connection_loss(rtlpriv->mac80211.vif);

and try again.

Thank you!
chaoming_li

Comment 32 Stefan Assmann 2011-08-24 10:20:53 UTC
chaoming_li,

commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); didn't make a difference either. Do you want the log?

Comment 33 chaoming_li 2011-08-25 01:27:37 UTC
(In reply to comment #32)
> chaoming_li,
> commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); didn't make a
> difference either. Do you want the log?

Yes, Please give me the log after commenting out ieee80211_connection_loss.

Thank you!

Comment 34 Stefan Assmann 2011-08-25 12:37:58 UTC
Created attachment 519833 [details]
dmesg-conloss.txt

Connected to a different AP this time.

Comment 35 Stefan Assmann 2011-10-14 08:42:40 UTC
chaoming_li,
do you have any news on this?

Comment 36 chaoming_li 2011-10-14 09:52:29 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > chaoming_li,
> > commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); didn't make a
> > difference either. Do you want the log?
> Yes, Please give me the log after commenting out ieee80211_connection_loss.
> Thank you!

Dear Sir:

I want you to commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); and give me the log, but in your log the ieee80211_connection_loss was not commented out, can you give me the log again.

Thank you!

Comment 37 Stefan Assmann 2011-10-14 10:06:10 UTC
weird I'm pretty sure I commented out ieee80211_connection_loss in the attachment in comment #34. Anyway I'll go prepare a new log just in case.

Comment 38 Stefan Assmann 2011-10-14 10:38:15 UTC
Created attachment 528189 [details]
dmesg-connection-loss-commented-out.txt

chaoming_li,
here's dmesg with commented out ieee80211_connection_loss(rtlpriv->mac80211.vif);

Hope this helps. Thanks!

Comment 39 chaoming_li 2011-10-17 01:07:07 UTC
(In reply to comment #38)
> Created attachment 528189 [details]
> dmesg-connection-loss-commented-out.txt
> chaoming_li,
> here's dmesg with commented out
> ieee80211_connection_loss(rtlpriv->mac80211.vif);
> Hope this helps. Thanks!

Dear Sir:

   I found that your AP will stop issue beacon, So after we test it we will reconnect it, because we think if AP stop beacon, maybe it's power off.
   But it's a normal condition for your AP to stop issue beacon sometimes, So I suggest you to commented out ieee80211_connection_loss, our update your AP' s firmware.

Thank you!
chaoming_li

Comment 40 Larry Finger 2011-10-17 02:20:36 UTC
To clarify, I think Chaoming meant to say "or update your AP's firmware". For whatever reason, when your AP stops sending beacons, the station (rtl8192ce) thinks it disappeared - it has no other choice. This is a bug in the AP firmware that we cannot work around in a general case. It would break too many other setups.

Comment 41 Stefan Assmann 2011-10-17 06:43:17 UTC
Ok, I'll try to update the firmware. Is there a way to capture beacon frames with for example tcpdump?

Comment 42 chaoming_li 2011-10-17 07:38:50 UTC
(In reply to comment #40)
> To clarify, I think Chaoming meant to say "or update your AP's firmware". For
> whatever reason, when your AP stops sending beacons, the station (rtl8192ce)
> thinks it disappeared - it has no other choice. This is a bug in the AP
> firmware that we cannot work around in a general case. It would break too many
> other setups.

Yes it's "or update your AP's firmware". 
Thank you!

Comment 43 Stanislaw Gruszka 2011-10-17 11:50:56 UTC
That of course could be an AP issue, but according to comment 23 other stations works with this AP.

Stefan, you can configure some other wireless interface in monitor mode, set channel to the same as used by your AP, and use wireshark to check if beacons are send from AP. In case they are send, you might try to configure rtl8192ce device to operate permanently in promiscuous mode (i.e ifconfig wlan0 promisc). If that would help with problem, it will indicate rtl8192ce issue, probably with filtering.

Comment 44 Stefan Assmann 2011-10-17 13:09:48 UTC
Stanislaw that sounds like a good idea, but I'm having trouble to capture beacon frames with my Intel PRO/Wireless 2200BG. I'm not seeing any packets at all.
What I tried was booting in runlevel 1 and then
iwconfig eth1 channel 8
ifconfig eth1 promisc
ifconfig eth1 up
tcpdump -v -i eth1

Any idea why I'm not seeing any traffic (beacons)? The device entered promiscuous mode.

Comment 45 Stanislaw Gruszka 2011-10-17 13:19:39 UTC
ipw2200 is not mac80211 driver, it crate separate interface for monitoring mode called rtap0 .

Comment 46 Stanislaw Gruszka 2011-10-17 13:45:04 UTC
I do not think tcpdump will show any wireless traffic, it's probably only usable for upper layers. For sure you can use tshark on console to sniff what happen on the air.

Comment 47 Stefan Assmann 2011-10-17 13:51:52 UTC
ok John told me to use 
ifconfig eth1 down ; iwconfig eth1 mode monitor ; ifconfig eth1 up
with my card.
That works great. Thanks John :)

Stanislaw, I'm now able to capture beacons and tcpdump works as well, so I'll report back as soon as I have done some testing.

Comment 48 Stefan Assmann 2011-10-17 15:15:23 UTC
Ok here are the results:
I've captured beacons with ipw2200 for over an hour and couldn't spot any period where the AP failed to send beacons. During that time there was a disassociate and reconnect on the rtl8192. Here's a short excerpt of the traffic captured.

16:54:51.369027 0us tsft 1.0 Mb/s 2447 MHz 11b -60dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.471459 0us tsft 1.0 Mb/s 2447 MHz 11b -60dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.527950 0us tsft 1.0 Mb/s 2447 MHz 11b -21dB signal 0dB noise antenna 1 Action (ec:55:f9:c8:df:41 (oui Unknown)): BA DELBA
16:54:51.528789 0us tsft 1.0 Mb/s 2447 MHz 11b -21dB signal 0dB noise antenna 1 Action (ec:55:f9:c8:df:41 (oui Unknown)): BA DELBA
16:54:51.529382 0us tsft 1.0 Mb/s 2447 MHz 11b -21dB signal 0dB noise antenna 1 Action (ec:55:f9:c8:df:41 (oui Unknown)): BA DELBA
16:54:51.546865 0us tsft 1.0 Mb/s 2447 MHz 11b -22dB signal 0dB noise antenna 1 DeAuthentication (ec:55:f9:c8:df:41 (oui Unknown)): Disassociated due to inactivity
16:54:51.547448 0us tsft 1.0 Mb/s 2447 MHz 11b -23dB signal 0dB noise antenna 1 DeAuthentication (ec:55:f9:c8:df:41 (oui Unknown)): Disassociated due to inactivity
16:54:51.573829 0us tsft 1.0 Mb/s 2447 MHz 11b -61dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.676263 0us tsft 1.0 Mb/s 2447 MHz 11b -61dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.778659 0us tsft 1.0 Mb/s 2447 MHz 11b -61dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]

I checked my dump before that issue and couldn't spot any irregularities in the beacons. Anyway I'll attach part my dump if anybody wants to take a closer look.

Comment 49 Stefan Assmann 2011-10-17 15:18:31 UTC
Created attachment 528562 [details]
beacons.txt

Comment 50 Stefan Assmann 2011-10-17 15:25:51 UTC
oh and please note that I only captured packets from the APs MAC address.

Comment 51 Stanislaw Gruszka 2011-10-18 10:55:53 UTC
So AP send beacons periodically, looks for some reason we stop to receive them via rtl8192ce device.

Did you try put rtl8192ce interface in permanent promiscuous mode to see if that workaround helps with problem?

Comment 52 Stefan Assmann 2011-10-18 12:00:25 UTC
I've now set
ifconfig wlan0 promisc
but the disconnect happened again.

Is that what you suggested?

Comment 53 Stanislaw Gruszka 2011-10-18 12:27:08 UTC
Yes, so reason not receiving beacons must be different.

Comment 54 Stanislaw Gruszka 2011-10-24 12:36:32 UTC
We have bug in mac80211, that make we do not correctly return to operating channel after doing some off-channel work i.e. scanning. I can image that bug can cause we stop receive beacons. I had build kernel, which include possible fixes for that issue, Stefan you might give it a try:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3443284

Comment 55 Stefan Assmann 2011-10-24 12:51:10 UTC
Stanislaw,
great find! I'm on f16 beta now, is this problem present there as well? If so could you attach the patch or brew a kernel for f16.
Thanks!

Comment 56 Stanislaw Gruszka 2011-10-24 13:02:59 UTC
Patches are here (they are not applied upstream currently):
http://marc.info/?l=linux-wireless&m=131914572421076&w=2
http://marc.info/?l=linux-wireless&m=131914572421077&w=2

Comment 57 Bill McGonigle 2011-11-02 02:36:39 UTC
I'm seeing this on f15 on an:

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
        Subsystem: AzureWave Device 1139
        Flags: bus master, fast devsel, latency 0, IRQ 18
        I/O ports at d000 [size=256]
        Memory at fea00000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: rtl8192ce
        Kernel modules: rtl8192ce

I have a Netgear WNDR3700v2 at work running OpenWRT (802.11n) and a Linksys WRT54GLv2 at home running DD-WRT (802.11g) and both exhibit this problem.  Both are pretty mainstream devices, so I'm guessing they don't have beacon problems.  Other clients with different hardware (also running f15) don't see these errors.

I'll post back here after trying Stanislaw's kernel patches.

Comment 58 Larry Finger 2011-11-02 03:22:11 UTC
For those of us that do not use Fedora, please state the kernel version used in F15.

Comment 59 Stanislaw Gruszka 2011-11-02 09:35:31 UTC
Currently fedora 15 use 3.0.x kernel, usually it is synced with latest release done by GregKH. We rename it to 2.6.40.x to do not break some applications relayed on kernel version. Newest kernel is 2.6.40.8-2.fc15 based on 3.0.8 .

Comment 60 Stanislaw Gruszka 2011-11-16 14:35:54 UTC
Latest F-16 kernel 3.1.1-1 include patches from comment 56 ...

Comment 61 Stefan Assmann 2011-11-16 14:47:43 UTC
Nice! I'll update and test. Thanks Stanislaw! :-)

Comment 62 Stefan Assmann 2011-11-18 16:42:19 UTC
So far no firmware reloads when wireless is disabled.

Comment 63 Larry Finger 2011-11-18 16:49:07 UTC
That should not surprise you. The firmware reloads happen when the wireless connection is dropped and the driver needs to reset before continuing.

No connection => no dropped connection.

Comment 64 Dan Winship 2011-11-19 18:24:23 UTC
The new kernel doesn't keep reloading the firmware, but it still drops the connection constantly.

Comment 65 Stefan Assmann 2011-11-22 08:28:09 UTC
(In reply to comment #63)
> That should not surprise you. The firmware reloads happen when the wireless
> connection is dropped and the driver needs to reset before continuing.
> 
> No connection => no dropped connection.

Larry, see the initial comment. I was seeing firmware reloads even though the network was not connected.

Dan, I'm also still seeing connection drops.

Comment 66 Stanislaw Gruszka 2011-11-23 14:17:33 UTC
Here is another kernel to test, it include full revert of off-channel rework happened between .38 and 3.0. It's for F-15, but it should be installeble for F-16 via "rpm -ivh --force"
http://koji.fedoraproject.org/koji/taskinfo?taskID=3534603
Please test.

Comment 67 Ivan Makfinsky 2011-11-23 15:08:48 UTC
Testing it now as I also have the same problem with the firmware reloading and dropping the connection.

Comment 68 Stanislaw Gruszka 2011-11-24 13:44:48 UTC
There was deadlock identified on previous kernel related with rtlwifi power save code, this one should have this problem fixed:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3536998

Comment 69 Stanislaw Gruszka 2011-11-25 11:34:15 UTC
Any feedback about above test kernel? Note you can install it on fedora 16 using either "rpm -ivh --oldpackag" or "rpm -ivh --force".

Comment 70 Stefan Assmann 2011-11-25 11:43:56 UTC
I ran the kernel from comment #66 a whole day now and experienced 4 deauths all with "Reason 6". Not exactly sure what Reason 6 means but I moved around with the machine a bit so maybe I got out of range?

If you think the kernel from comment #68 is worth another shot let me know and I'll switch. From the 1 day experience I'd say that kernel works better but since it's only been such a short period since I ran it that might not be true.

Comment 71 Stanislaw Gruszka 2011-11-25 11:58:31 UTC
There is not difference between #66 and #68 as long as #66 do not hung.

Reason 6 is WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA, but this do not tell much as well, generally looks like problem with autentification/encryption. You might try swenc=1 module parameter. However I do not thing this is related to bug originally reported here.

Comment 72 Stanislaw Gruszka 2011-11-25 12:01:09 UTC
I forgot about important question, is there difference between fedora 16 kernel 3.1.x and kernel from comment #66 ?

Comment 73 Stefan Assmann 2011-11-25 12:05:37 UTC
The deauth is always followed by a firmware reload. I'll try again with the
kernel from #68 with swenc=1.

To answer your question, I'm not sure yet, my impression is that it works more reliably but please give me a bit more time for testing. :)

Comment 74 Dan Winship 2011-11-26 19:12:16 UTC
Hm... everyone experiencing this bug is using DD-WRT or OpenWRT (comment 28, comment 57. I'm running OpenWRT on a D-Link DIR 825). And while traveling for Thanksgiving, I've been in two houses with Apple Airports and have had no problem with the connection...

Comment 75 Dan Winship 2011-11-26 19:34:37 UTC
(oops, wrote the above comment without having seen the past few days discussion.)

Comment 76 Stanislaw Gruszka 2011-11-28 16:07:14 UTC
I realized that my revert of off-channel rework missed one hunk. Here is kernel with missed hunk applied:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3545961
Except that, it include everything that kernel from comment 68, and it's for F-16. Maybe missed hung fixes these remaining connection drops with Reason 6.

Comment 77 Stefan Assmann 2011-11-29 07:33:58 UTC
ok I'll update to the latest kernel today.

Comment 78 Stanislaw Gruszka 2011-11-29 09:24:30 UTC
Created attachment 537847 [details]
mac80211_offchannel_rework_revert_v2.patch

For non-fedora users: off-channel rework revert patch applied in kernel from comment 76. This kernel also include patch from bug 755154 .

Comment 79 Stefan Assmann 2011-11-29 09:49:56 UTC
No more disconnects with Reason 6 with the new kernel. Now I frequently get the following (happened 3-4 times already).

[ 1673.662748] cfg80211: Calling CRDA to update world regulatory domain
[ 1673.675925] cfg80211: World regulatory domain updated:
[ 1673.675940] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1673.675952] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1673.675962] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1673.675972] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1673.675982] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1673.675991] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1673.676103] cfg80211: Calling CRDA for country: DE
[ 1673.688743] cfg80211: Regulatory domain changed to country: DE
[ 1673.688751] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1673.688759] cfg80211:     (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1673.688765] cfg80211:     (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1673.688771] cfg80211:     (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1673.688777] cfg80211:     (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
[ 1673.761048] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 1675.044087] wlan0: authenticate with 00:18:e7:da:f1:24 (try 1)
[ 1675.046691] wlan0: authenticated
[ 1675.047280] wlan0: associate with 00:18:e7:da:f1:24 (try 1)
[ 1675.051367] wlan0: RX ReassocResp from 00:18:e7:da:f1:24 (capab=0x431 status=0 aid=2)
[ 1675.051377] wlan0: associated

Comment 80 Jim Rees 2011-12-06 03:56:00 UTC
Is there some way to turn off all power save features? I tried setting fwlps=0 but it looks like this setting gets ignored. I'm still getting disconnects after a period of inactivity, but no firmware reloads, so I'm not sure whether I'm seeing this bug or a different one. Dmesg is here:
http://jim.rees.org/rtl-powersave-2-dmesg.txt

Comment 81 Larry Finger 2011-12-06 04:06:38 UTC
Your dmesg output does not show any disconnects that I could find. Run without any "debug=" option.

The module parameters are as follows:

parm:           swenc:Set to 1 for software crypto (default 0)
 (bool)
parm:           ips:Set to 0 to not use link power save (default 1)
 (bool)
parm:           swlps:Set to 1 to use SW control power save (default 0)
 (bool)
parm:           fwlps:Set to 1 to use FW control power save (default 1)
 (bool)
parm:           debug:Set debug level (0-5) (default 0) (int)


Load the driver with 'ips=0' to disable power saving.

Comment 82 Stanislaw Gruszka 2011-12-12 16:03:04 UTC
F-16 kernel kernel-3.1.5-1.fc16 include patch that revert mac80211 off-channel switches, I consider this as fix for "constant firmware reload problem".
http://koji.fedoraproject.org/koji/buildinfo?buildID=278322

I do not want to mess this bug report with too many comments, so if you have any other problem with rtlwifi driver just open a new bug report for that specific problem.

Comment 83 Bill McGonigle 2011-12-14 19:50:56 UTC
Created attachment 546859 [details]
dmesg 2.6.41.5-1.fc15.x86_64

I'm still seeing this on f15 with the same kernel version - anything special about the f16 version?

[   53.059133] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[  866.503814] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[10586.504574] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[12146.505770] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[13226.503827] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[13346.504784] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[19706.499035] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[20426.501822] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[20546.504744] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
...

Comment 84 Larry Finger 2011-12-14 21:16:44 UTC
I cannot answer the question about Fedora kernels; however, I can provide some additional information.

The earliest version of the driver had code so that the firmware is only reloaded when not actually present. Thus, the firmware is NOT being reloaded, no matter what the log says.

A new patch (commit 8ff08b4) makes the message be logged only when the firmware is actually loaded. This patch is present in the wireless-testing tree, but not in the mainline kernel. It is possible that John Linville has applied this patch to Fedora kernels. It will appear in mainline in kernel 3.3 - it is not a serious enough bug to be pushed into 3.2 or any stable kernel.

What I think you are seeing is a temporary disconnection because the driver fails to transmit a nullfunc packet and return success to the upper levels. I have not been able to find a flaw in the code. As this condition happens infrequently, it is difficult to determine if the packet has been transmitted or not.

Comment 85 W Agtail 2011-12-27 23:24:31 UTC
Hello
It looks as though I am having the same issue with Fedora 16 and am unable to connect to my AP.

Not sure if this bit helps:
When I did an initial install of F16 from the DVD, my wireless connection seemed all OK. I applied all updates and all was still OK. I then tried an install via kickstart and only managed to connect to my AP the odd time for a few seconds. I've since gone back to a new install from the DVD and applied a kernel update via a wired connected. All is fine via Windoze 7 (sorry to mention that bit).

Should you require more info, please let me know.

Some system errors/stats:

:> dmesg | tail -2
[ 2204.007965] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 2264.007474] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin

Currently on kernel:
:> uname -srm
Linux 3.1.6-1.fc16.x86_64 x86_64

I am using a Lenovo E525 laptop with this card:
:> lspci -vvv
05:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 8195
	Physical Slot: 0
	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: 32 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at 2000 [size=256]
	Region 2: Memory at f0900000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
	Capabilities: [160 v1] Device Serial Number 01-91-81-fe-ff-4c-e0-00
	Kernel driver in use: rtl8192ce
	Kernel modules: rtl8192ce

Comment 86 Larry Finger 2011-12-27 23:56:18 UTC
I do not understand what you did. I'm not a Fedora user and the jargon is foreign to me.

As I read this, the first installation was OK. After an update, it was still OK. Then you did a reinstall and updated again, then it doesn't work. Is that an accurate description of what you did?

Comment 87 W Agtail 2011-12-28 15:30:33 UTC
Hello and thank you for your response.
Yes, this that is an accurate description of what I did. Although, just for clarity, between the second reinstall and update, it didn't work either.

Comment 88 Larry Finger 2011-12-28 15:47:50 UTC
I downloaded the F16 live CD last night. My rtl8192ce device worked with WPA2-AES encryption with the live system. I then installed on my disk. Again, the wireless worked. I then used it to update (282 packages). It still worked.

Sorry, but I am unable to duplicate your results with F16.

Comment 89 W Agtail 2011-12-28 17:20:31 UTC
The only other thing I can add, is that I am using a WEP key. Thanks.

Comment 90 Larry Finger 2011-12-28 19:10:25 UTC
I just booted into my patched F16 and was able to connect to an AP running WEP, and one running WPA-TKIP, as well as WPA2.

On your WEP, are you using a hex key, or passphrase? My test was with the 28-digit hex key.

Comment 91 Bill McGonigle 2011-12-29 22:07:53 UTC
(In reply to comment #86)
> I do not understand what you did. I'm not a Fedora user and the jargon is
> foreign to me.

Larry - kickstart is a scripted install (vs. using the step-by-step installer).

W Agtail - can you post your kickstart file?  There may be a different set of packages selected.

Comment 92 Andrew Ash 2012-01-01 00:44:08 UTC
I know it's not particularly useful, but I'm seeing this bug as well on ArchLinux, running kernel 3.1.6-1. Other than a few unrelated patches, it's a stock vanilla kernel -- http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux

My observations of spontaneous disconnects are identical to Stefan's, but more frequent.  On this router, I can consistently repro within a few minutes of starting a connection.  I can disconnect and reconnect using network manager, but the connection dies soon thereafter again.

The router is a Netgear with a WPA2 TKIP-PSK network.  The bug seems to be network-specific though, since my home router (not the netgear) has never shown this automatic disconnecting behavior.  Perhaps the bug lies in a particular network encryption scheme?  Oddly enough, I'm completely unable to observe the spontaneous disconnects in another part of the flat, so the behavior may be tied to reception quality as well.  I feel closer to the access point where the disconnects are happening, though reception may be quantitatively poorer there instead.

I'm unable to test many of the other suggestions at the moment since I'm a guest on this network while traveling, but have seen this occur one other time as well.  The next time I'm near a network where I can reproduce, I'd love to help.

Thanks for all the work guys!

lspci -vv:
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 8195

lspci -vvn:
03:00.0 0280: 10ec:8176 (rev 01)
	Subsystem: 10ec:8195

dmesg:
[ 6505.714108] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 6505.979776] wlan0: authenticate with c4:3d:c7:xx:xx:xx (try 1)
[ 6505.981363] wlan0: authenticated
[ 6505.983223] wlan0: associate with c4:3d:c7:xx:xx:xx (try 1)
[ 6506.986924] wlan0: RX ReassocResp from c4:3d:c7:xx:xx:xx (capab=0x411 status=0 aid=5)
[ 6506.986929] wlan0: associated

lsmod | grep rtl:
rtl8192ce			72695	0
rtl8192c_common	56668	1	rtl8192ce
rtlwifi			91668	1	rtl8192ce
mac80211		222059	3	rtl8192ce,rtl8192c_common,rtlwifi
cfg80211			165796	2	rtlwifi,mac80211
usbcore			144432	4	uvcvideo,rtlwifi,ehci_hcd

Comment 93 W Agtail 2012-01-01 21:48:45 UTC
Hi Bill

Over the last few days I've been running several kickstart installs from the F16 DVD. Sometimes my wireless works, sometimes it does not. I am using a 26 char hex WEP key.

I am attaching the following files:
ks.cfg        # kickstart file.
ifcfg-space   # installed via kickstart (post).
keys-space    # installed via kickstart (post).
iwconfig.txt  # iwconfig wlan0 output.

At the moment, wireless is working OK, although 'iwconfig wlan0' shows 'Encryption key:off'. On previous versions of Fedora, 'Encryption key' shows the actual WEP key. Although it currently shows off, I can ping my AP and surf the web OK.

Happy New Year to all.

Comment 94 W Agtail 2012-01-01 21:50:03 UTC
Created attachment 550164 [details]
kickstart file

Comment 95 W Agtail 2012-01-01 21:51:50 UTC
Created attachment 550165 [details]
/etc/sysconfig/network-scripts

Comment 96 W Agtail 2012-01-01 21:52:22 UTC
Created attachment 550166 [details]
/etc/sysconfig/network-scripts

Comment 97 W Agtail 2012-01-01 21:53:06 UTC
Created attachment 550167 [details]
output from 'iwconfig wlan0'

Comment 98 W Agtail 2012-01-01 22:03:00 UTC
Created attachment 550168 [details]
kickstart file ks.cfg

Comment 99 W Agtail 2012-01-02 04:39:55 UTC
Hi
I have now applied all Fedora 16 updates via a wired cable.
I can confirm my wifi connection is still unstable. I just recently ran this:
dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true

dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"

After starting with no wireless connection, I made many attempts connecting via wireless. For this test I simply selected my AP (space) from the WiFI icon on Gnome Classic Desktop. After a good while, the connection was made. Ping testing to my AP ranges from 1-2ms (the odd time), but mainly 'Destination Host Unreachable' or anything around 10000 - 28000 ms.

Please find attached files:
messages
wpa_supplicant.log

Hope these findings are a bit more useful.

Comment 100 W Agtail 2012-01-02 04:41:42 UTC
Created attachment 550183 [details]
messages

Comment 101 W Agtail 2012-01-02 04:42:32 UTC
Created attachment 550184 [details]
wpa_supplicant.log

Comment 102 W Agtail 2012-02-17 18:53:53 UTC
Hello
I am now running with kernel 3.2.6-3.fc16.x86_64.
My wireless network connection periodically 'stalls'.
After 100 icmp_reqs (ping test) to my router,the following was observed:
1) ~1.50ms time is generally displayed.
2) 6% packet loss.
3) slowest times range from 326ms to 4000ms.
Kind regards

Comment 103 Larry Finger 2012-02-19 17:50:00 UTC
This thread has strayed quite a ways from the original topic.

The kind of packet losses that you report are frequently the result of interference. Have you tried switching the router to a different channel?

When I do a 100 ping set to one of the hosts on my network, I get the following:

100 packets transmitted, 100 received, 0% packet loss, time 99151ms
rtt min/avg/max/mdev = 1.624/8.196/138.168/25.214 ms

This performance is satisfactory.

Comment 104 W Agtail 2012-02-22 17:43:12 UTC
Hi all
Well this is going to sound odd. I have been kickstarting F16 from a DVD with a kickstart file on a USB memory stick. While the memory stick is mounted, my WiFi connection either struggles to connect, drops, ping rate is poor or ping times out. While the USB memory stick is disconnected, my WiFi connection is excellent. Another USB memory stick, which is the same, also produces WiFi problems. Two other different USB memory sticks do not cause any WiFi problems. My issue must be down to some strange USB memory sticks.

Comment 105 Stanislaw Gruszka 2012-02-22 18:31:29 UTC
So this is different issue, open separate bug report for it.

Stefan, is problem you reported here in comment 0 fixed?

If so we will close that bug, mixing different issues in one bug report is not good.

Comment 106 Stefan Assmann 2012-02-23 07:37:24 UTC
Yes, I no longer see the firmware reload messages. The connection is still not stable, but that is a different issue.

Comment 107 Stanislaw Gruszka 2012-02-23 08:19:10 UTC
Ok, so let's close this bug report. For other issues please open a separate bugzillas.


Note You need to log in before you can comment on or make changes to this bug.