RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 820167 - scanning failure after doing wireless roaming on iwl6205
Summary: scanning failure after doing wireless roaming on iwl6205
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Stanislaw Gruszka
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 766952 808095 814674
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-09 10:13 UTC by Stanislaw Gruszka
Modified: 2013-01-11 04:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 814674
Environment:
Last Closed: 2012-05-15 10:17:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
test-roam2 (2.56 KB, text/plain)
2012-05-09 10:15 UTC, Stanislaw Gruszka 		no flags Details
Everything in one file (1.40 MB, application/x-compressed-tar)
2012-05-09 11:51 UTC, Thorsten Hesemeyer 		no flags Details
wpa_supplicant.log files from today and yesterday (14.23 MB, application/x-compressed-tar)
2012-05-09 12:19 UTC, Thorsten Hesemeyer 		no flags Details
View All

Description Stanislaw Gruszka 2012-05-09 10:13:47 UTC 
Steps to reproduce:
sudo service NetworkManager stop
sudo killall wpa_supplicant
sudo /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf
-B -u -dddt -i wlan0 -D nl80211 -f /var/log/wpa_supplicant.log

Run roaming testing script.

Results:
After a while device is unable to scan, and roaming is not performed, only one AP is visible.

iwlist wlan0 scan
wlan0     Failed to read scan data : Resource temporarily unavailable

Additional info:
This happen on laptop with iwl 6205, problem is not reproducible on laptop with 5100 adapter.
Comment 1 Stanislaw Gruszka 2012-05-09 10:15:43 UTC 
Created attachment 583207 [details]
test-roam2

Roaming testing script.
Comment 2 Stanislaw Gruszka 2012-05-09 10:19:35 UTC 
Issue is not reproducible on RHEL6.3 beta kernel - Thorsten, is that correct?
Comment 4 Thorsten Hesemeyer 2012-05-09 11:51:06 UTC 
Created attachment 583235 [details]
Everything in one file

Hi,

I've put together in one tgz file:
  test-roam2   ... script used (just to be complete)
  dmesg.txt    ... output of dmesg command
  sosreport*   ... files from sosreport of my T420
  (other)      ... ifconfig -a and some more output
The folder var/log/ contains log files from /var/log/
  dmesg        ... /var/log/dmesg file
  messages     ... /var/log/messages file
  wpa_supplicant.log ... /var/log/wpa_supplicant.log file with timestamps and debugging information
  test-roam.log... /var/log/test-roam.log file written by the script above.

The test-roam.log file contains the following fields:
  #1 number of access points found while scanning 
  #2 Date&Time /human readable,
  #3 Time in seconds since 1970
  #4 Uptime Idle in seconds
  #5 Uptime in seconds
Meant to make it easier to join and find the different time stamps from dmesg, messages and other log files.

Kind regards,
Thorsten
Comment 5 Thorsten Hesemeyer 2012-05-09 11:56:27 UTC 
Hi,

the test-roam.log file gives an overview what happened:
  a) started 05/08/12 08:21:14
  b) after 05/08/12 10:26:42 only and exactly one access point visible
  c) after 05/08/12 21:49:45 no access point visible

I was astonished to see there was no access point left over this morning.
But I guess that is really good for finding the issue.

Kind regards,
Thorsten
Comment 6 Thorsten Hesemeyer 2012-05-09 12:19:50 UTC 
Created attachment 583258 [details]
wpa_supplicant.log files from today and yesterday

Hi,

just noticed, the wpa_supplicant information has been log-rotated. 
Here's the information you probably will like to have:
  var/log/wpa_supplicant.log-20120508
  var/log/wpa_supplicant.log-20120509

Kind regards,
Thorsten
Comment 8 Stanislaw Gruszka 2012-05-10 10:44:12 UTC 
This problem is fixed on RHEL6.3, but we need to find a patch for RHEL6.2.
Comment 10 Thorsten Hesemeyer 2012-05-10 11:15:02 UTC 
Hi Stanislaw,

agreed, tested RHEL63 starting yesterday - issue did not occur:
  RHEL62 - usually occurs after a some minutes or one/two hours
  RHEL63 - does not occur even when roaming more than 24h

Kind regards,
Thorsten
Comment 11 Stanislaw Gruszka 2012-05-15 10:17:11 UTC 
This issue is not a bug on RHEL6.2 release, but rather bug in one of my test patches, claiming to fix 814674 (wireless roaming test on raw RHEL6.2 kernel will trigger a crash).

There was a race condition that mark scanning as pending, but do not perform actual scan and scan pending state was never unmarked. New scan request finished with -EBUSY (Resource temporarily unavailable) error. Hence after some time there was no AP visible except currently associated one, since kernel internally time out old APs information.
Note You need to log in before you can comment on or make changes to this bug.