lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6a2187b0903160624gb9d207dv301506e589d93ed4@mail.gmail.com>
Date:	Mon, 16 Mar 2009 21:24:14 +0800
From:	Jeff Chua <jeff.chua.linux@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Johannes Berg <johannes@...solutions.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: 2.6.29-rc8: Reported regressions from 2.6.28

On Mon, Mar 16, 2009 at 4:26 AM, Ingo Molnar <mingo@...e.hu> wrote:
> * Johannes Berg <johannes@...solutions.net> wrote:
>> that the commit he quotes doesn't even change the driver he's
>> working with.

Here's what I did, and it's repeatable.

Take the attached bisect log and replay it, and the last offending
commit is this ...
# git log
commit 71c11fb57b924c160297ccd9e1761db598d00ac2
Author: Johannes Berg <johannes@...solutions.net>
Date:   Tue Oct 28 18:29:48 2008 +0100

    b43/legacy: remove SSID code

Yes, this is not the real problem, but it's the last commit that cause
the problem, and I couldn't bisect further, typing the next "git
bisect bad" and the commit is

# git bisect bad
71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
commit 71c11fb57b924c160297ccd9e1761db598d00ac2
Author: Johannes Berg <johannes@...solutions.net>
Date:   Tue Oct 28 18:29:48 2008 +0100

    b43/legacy: remove SSID code


Johannes, Ok, this is not the commit causing the problem, but anything
after this commit doesn't associate with my hidden APs. I may not have
run over every single commits since, but 2.6.29-rc8 is definitely not
associating at all automatically -- only manually by specifying the
AP.

This bug is quite hard to trigger, and it doesn't shows easily in
2.6.28-rc3. May be once every 10 times you tried.



# git reset --hard 71c11fb57b924c160297ccd9e1761db598d00ac2

I've tried on two different Linksys's AP. Association with WAG354G  is
better than with WAG200G ... meaning it's harder to get association
failure on 2.6.28-rc3. 1/10 fail on WAG354G, and 9/10 fails on
WAG200G.

Here's how I associate with the AP.

# modprobe -r iwlagn
# modprobe iwlagn
# iwconfig wlan0 mode Managed
# ifconfig wlan0 up
# iwconfig wlan0 essid "myessid"
# iwconfig wlan0 key restricted "hex key"
# iwconfig wlan0 ap auto channel auto
# ... wait for association
# ping -c 3 <IP of the AP>
# shutdown the interface
# ifconfig wlan0 down
# modprobe -r iwlagn


Repeat these and it'll fail to associate. On WAG200G, can't associate
after 2nd attempt.


Next revert these two commits

commit 4607816f608b42a5379aca97ceed08378804c99f
Author: Johannes Berg <johannes@...solutions.net>
Date:   Tue Oct 28 18:25:43 2008 +0100

    iwlwifi: remove unused essid variable

commit a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
Author: Johannes Berg <johannes@...solutions.net>
Date:   Tue Oct 28 18:21:05 2008 +0100

    iwlwifi: remove implicit direct scan


With these patches reverted, associating with the APs are always
successful 10 out of 10 times with the same steps as above.

I've even used the bad modules and when it failed, I can associate
again with the patched module. Same 2.6.28-rc3 kernel.


Here's part of the dmesg
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
        (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
        (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
iwlagn: Copyright(c) 2003-2008 Intel Corporation
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: setting latency timer to 64
iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwlagn: Tunable channels: 11 802.11bg, 13 802.11a channels
iwlagn 0000:03:00.0: PCI INT A disabled
wmaster0 (iwlagn): not using net_device_ops yet
phy0: Selected rate control algorithm 'iwl-agn-rs'
wlan0 (iwlagn): not using net_device_ops yet
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: restoring config space at offset 0x1 (was
0x100102, writing 0
x100106)
iwlagn 0000:03:00.0: irq 28 for MSI/MSI-X
iwlagn 0000:03:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn loaded firmware version 228.57.2.23
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
iwlagn: TX Power requested while scanning!

Anything I can help to debug further, just let me know.

Thanks,
Jeff.

Download attachment "bisect.log" of type "application/octet-stream" (2095 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ