Red Hat Bugzilla – Bug 860742
[iwlwifi] unstable network connection
Last modified: 2012-10-17 05:26:49 EDT
Description of problem: The eduroam network (a secure international roaming service for users in Higher Education) was consistently failling in this laptop. Network manager is asking for a password expecting that the failure problem is due to a wrong username/password combination frequently. The same error appeared yesterday on the same conditions. Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 cmdline: BOOT_IMAGE=/boot/vmlinuz-3.5.4-1.fc17.x86_64 root=UUID=4f1009da-df5d-4364-9aef-b3072bdfabbb ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=pt-latin1 rd.luks=0 LANG=en_US.UTF-8 rhgb quiet kernel: 3.5.4-1.fc17.x86_64 backtrace: :WARNING: at net/wireless/mlme.c:491 cfg80211_mlme_disassoc+0x112/0x120 [cfg80211]() :Hardware name: HP EliteBook 8530p :Modules linked in: ppp_async crc_ccitt ppp_generic slhc lockd sunrpc rfcomm bnep nf_conntrack_ipv4 nf_conntrack_netbios_ns nf_conntrack_broadcast nf_defrag_ipv4 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state ip6table_filter ip6_tables nf_conntrack snd_hda_codec_hdmi snd_hda_codec_analog arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_seq cfg80211 uvcvideo hp_wmi videobuf2_vmalloc videobuf2_memops videobuf2_core snd_seq_device btusb bluetooth videodev sparse_keymap rfkill snd_pcm media snd_page_alloc coretemp snd_timer hp_accel snd kvm_intel kvm pata_pcmcia soundcore r592 ppdev lis3lv02d e1000e mei lpc_ich mfd_core memstick serio_raw parport_pc parport input_polldev microcode uinput yenta_socket sdhci_pci sdhci firewire_ohci mmc_core firewire_core crc_itu_t ata_generic pata_acpi wmi video hid_logitech_dj radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan] :Pid: 752, comm: wpa_supplicant Not tainted 3.5.4-1.fc17.x86_64 #1 :Call Trace: : [<ffffffff8105867f>] warn_slowpath_common+0x7f/0xc0 : [<ffffffff810586da>] warn_slowpath_null+0x1a/0x20 : [<ffffffffa04212b2>] cfg80211_mlme_disassoc+0x112/0x120 [cfg80211] : [<ffffffff8160a72d>] ? mutex_lock+0x1d/0x50 : [<ffffffffa0411e93>] nl80211_disassociate+0xb3/0xf0 [cfg80211] : [<ffffffff81528bd0>] genl_rcv_msg+0x250/0x2d0 : [<ffffffff81528980>] ? genl_rcv+0x40/0x40 : [<ffffffff815284f1>] netlink_rcv_skb+0xa1/0xb0 : [<ffffffff81528965>] genl_rcv+0x25/0x40 : [<ffffffff81527e6d>] netlink_unicast+0x19d/0x220 : [<ffffffff815281e2>] netlink_sendmsg+0x2f2/0x370 : [<ffffffff814e8188>] sock_sendmsg+0xf8/0x130 : [<ffffffff81126756>] ? __generic_file_aio_write+0x236/0x440 : [<ffffffff811269fa>] ? generic_file_aio_write+0x9a/0xe0 : [<ffffffff814e935a>] ? move_addr_to_kernel+0x5a/0xc0 : [<ffffffff814f56a6>] ? verify_iovec+0x56/0xd0 : [<ffffffff814e85cc>] __sys_sendmsg+0x3ac/0x3c0 : [<ffffffff8119b401>] ? core_sys_select+0x2a1/0x350 : [<ffffffff81187b36>] ? do_sync_write+0xe6/0x120 : [<ffffffff811c53db>] ? fsnotify+0x24b/0x340 : [<ffffffff814ea299>] sys_sendmsg+0x49/0x90 : [<ffffffff81614e29>] system_call_fastpath+0x16/0x1b
*** This bug has been marked as a duplicate of bug 834158 ***
https://bugzilla.redhat.com/show_bug.cgi?id=834158#c14
Please provide output of "iw dev wlan0 scan" command, which will show parameters of eduroam network . And "lspci -vnn" showing your hardware model.
Created attachment 628147 [details] Result from running "iw dev wlan0 scan"
Created attachment 628148 [details] lspci output
First thing I can tell from comment 4 scan results, is that the "eduraoam" signal is quite weak: -85dB and -89dB. I think this is reason of the problems. I'm not sure if Station is expect to work on such conditions (probably it is, but don't expect good performance). Are you sure things were better with 3.4 kernel, can you recheck that? If so, maybe there is iwlwifi rx sensitivity regression.
Oops, you are right. I used to control this but I forgot it due to the kernel backtrace above. After consulting the IT guys here they found that our nearest AP is broken and so the signal that I got was from others APs. They were not aware of the situation until the moment I report it. Thanks.
Ok, so do we have anything to fix here?
I suspect not. The original report does not happen anymore with 3.6.x kernels. so I think that we can fix this as closed -> current release.