Bug 12414

Could you add a line like this to /etc/modprobe.conf?

   options iwlagn disable_hw_scan=1

After that, either reboot or 'modprobe -r iwlagn ; modprobe iwlagn'.  Does that change the situation?

On Tuesday 20 January 2009, Jeff Chua wrote:
> On Tue, Jan 20, 2009 at 5:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> > Subject         : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> > Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> > Date            : 2009-01-05 4:13 (15 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> 
> Still not fixed. It seems to work if the AP is not hidden, but doesn't
> work if the AP is hidden -- on 2.6.27, it works fine.

Could you please try with patch http://marc.info/?l=linux-wireless&m=123320213115108&w=2 ? Even though it is a patch against latest wireless-testing it does apply to 2.6.29-rc3.

On Wednesday 04 February 2009, Jeff Chua wrote:
> On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> > Subject         : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> > Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> > Date            : 2009-01-05 4:13 (31 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> 
> Latest linux git pull seems to behave slightly better. Restarting the
> interface a few times fixes the problem 70% of the time. The rest of
> the time, it can't associate with the AP.

On Saturday 14 February 2009, Jeff Chua wrote:
> On Sat, Feb 14, 2009 at 7:41 PM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> >> Subject         : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> >> Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> >> Date            : 2009-01-05 4:13 (31 days old)
> >> References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> >
> > I applied the patch
> > http://marc.info/?l=linux-wireless&m=123320213115108&w=2 and it seems
> > better now. One instant of not association out of 20 tries, but
> > reloading the modules seems to make it work again. So, let's just
> > close the case?
> 
> I tested on another AP (WAG200G ), and this one, it's failing to
> associate more often. And I noticed that when it does associate, I
> don't get these two lines ...
> 
> iwlagn: TX Power requested while scanning!
> iwlagn: Error sending TX power (-11)
> 
> 
> 
> Here's a good run ...
> 
> 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
> 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: 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
> wlan0: authenticate with AP xxxxxxxxxxxxx
> wlan0: authenticate with AP xxxxxxxxxxxxx
> wlan0: authenticate with AP xxxxxxxxxxxxx
> wlan0: authenticated
> wlan0: associate with AP xxxxxxxxxxxx
> wlan0: RX AssocResp from xxxxxxxxxxxx (capab=0x471 status=0 aid=1)
> wlan0: associated

Any chance we could get the actual bug reporter Cc'ed on this bug?

Honestly, this seems like a rambling description of every glitch or problem the user is experiencing, rather than a focused report on a single problem.

From comment 5, it seems like maybe this one should be closed and a new bug should be opened for the "iwlagn: Error sending TX power (-11)" bits?

On Tuesday 24 February 2009, you wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12414
>
> ------- Comment #6 from linville@tuxdriver.com  2009-02-24 08:03 -------
> Any chance we could get the actual bug reporter Cc'ed on this bug?
> 
> Honestly, this seems like a rambling description of every glitch or problem
> the
> user is experiencing, rather than a focused report on a single problem.
> 
> From comment 5, it seems like maybe this one should be closed and a new bug
> should be opened for the "iwlagn: Error sending TX power (-11)" bits?

Jeff, this is a "NEEDINFO" for you, please respond.

Reply-To: jeff.chua.linux@gmail.com

On Thu, Feb 26, 2009 at 6:39 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=12414
> Jeff, this is a "NEEDINFO" for you, please respond.

I just tried it and still doesn't work. May be it's this particular
AP, but I tried on another hidden AP and it's not much better.

I'll try to bisect it. I know it works in 2.6.28.

Jeff.

Reply-To: jeff.chua.linux@gmail.com

On Thu, Feb 26, 2009 at 9:38 AM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 6:39 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> http://bugzilla.kernel.org/show_bug.cgi?id=12414
>> Jeff, this is a "NEEDINFO" for you, please respond.
>
> I just tried it and still doesn't work. May be it's this particular
> AP, but I tried on another hidden AP and it's not much better.
>
> I'll try to bisect it. I know it works in 2.6.28.

Here's the commit that causes the Intel 4965 to not associate with a
hidden AP. Reverting this commit make 2.6.28-rc3 works again very
reliably -- getting associated to the AP after every iwlagn module
reload.

But when I reverted this commit in 2.6.29-rc6, my X61 can't associate
with the hidden AP. Some other thing is broken in between 2.6.28 -
2.6.29.

The only way to associate in 2.6.29-rcX is to force it manually with
"iwconfig wlan0 ap <mac addr of hidden ap>".

In 2.6.28, I could just specify the ssid and encrypted key using
iwconfig, and then set "iwconfig wlan0 ap auto channel auto" and
"iwlist scan" will find the hidden ap.

Test on both 2.6.28 and 2.6.29-rcx using same
iwlwifi-4965-ucode-228.57.2.23 and wireless_tools.30.pre7.

What's the best way to get this fixed? I've tried git bisect and
trying to revert the bad commit, but it doesn't compile.

drivers/net/wireless/iwlwifi/iwl-scan.c:746: error: 'struct iwl_priv'
has no member named 'essid_len'
drivers/net/wireless/iwlwifi/iwl-scan.c:750: error: 'struct iwl_priv'
has no member named 'essid_len'
drivers/net/wireless/iwlwifi/iwl-scan.c:751: error: 'struct iwl_priv'
has no member named 'essid_len'


Thanks,
Jeff.



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

    iwlwifi: remove implicit direct scan

    When an undirected scan is requested and iwlwifi is not associated but
    the user has set an SSID (and maybe was associated with that network at
    some point) then iwlwifi will assume the user wanted to scan for this
    SSID which seems wrong. Remove this code.

    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Reply-To: jeff.chua.linux@gmail.com

On Sat, Feb 28, 2009 at 7:24 AM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:

>> I just tried it and still doesn't work. May be it's this particular
>> AP, but I tried on another hidden AP and it's not much better.

I just to clarify that this association problem only happens with
"hidden AP". 2.6.28 to 2.6.29-rcX works just fine with non-hidden AP.

Thanks,
Jeff.

On Sunday 15 March 2009, Jeff Chua wrote:
> On Sun, Mar 15, 2009 at 3:01 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> > Subject         : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> > Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> > Date            : 2009-01-05 4:13 (69 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> 
> Still not working in linux-2.6.29-rc8. Broken after the commit below.
> There were many changes to wireless after this commit, and simply
> reverting this commit will break compiling.
 
commit 41bb73eeac5ff5fb217257ba33b654747b3abf11
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Wed Oct 29 01:09:37 2008 +0100
 
     mac80211: remove SSID driver code


First-Bad-Commit : 41bb73eeac5ff5fb217257ba33b654747b3abf11

On Sunday 15 March 2009, Jeff Chua wrote:
> On Sun, Mar 15, 2009 at 10:58 AM, Jeff Chua <jeff.chua.linux@gmail.com>
> wrote:
> > On Sun, Mar 15, 2009 at 3:01 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> >> Subject         : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> >> Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> >> Date            : 2009-01-05 4:13 (69 days old)
> >> References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> >
> The commit below is causing problem with associating with the hidden AP as
> well.
> 
> 71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
> commit 71c11fb57b924c160297ccd9e1761db598d00ac2
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date:   Tue Oct 28 18:29:48 2008 +0100
> 
>     b43/legacy: remove SSID code
> 
>     The SSID programmed into the device is used by the ucode only
>     to reply to probe requests, a functionality we disable anyway
>     because it doesn't fit with the mac80211/hostapd programming
>     model. Therefore, it isn't useful to program the SSID into
>     device.
> 
>     Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>

Comment 9 identified "iwlwifi: remove implicit direct scan" as the culprit, which seems reasonable.  The other cited commits seem questionable.

Can you try a 2.6.29-rc8 build with this on top?

   git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9

Does that restore operation with hidden SSIDs for you?

Sorry, obviously you have to revert a few more...

git revert 41bb73eeac5ff5fb217257ba33b654747b3abf11
git revert b23f99bcfa12c7b452f7ad201ea5921534d4e9ff
git revert 71c11fb57b924c160297ccd9e1761db598d00ac2
git revert 4607816f608b42a5379aca97ceed08378804c99f
git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9

The first one generates a conflict, just take the hunk.

Created attachment 20567 [details]
revert-remove-ssid-knowledge-from-driver-series.patch

Equivalent patch to prescribed git revert sequence...

When in 2.6.29-rc8, can you see the hidden AP in your scan results?

What happens if you specify the ssid in iwconfig:
iwconfig wlanX ap auto channel auto essid <your essid>

On Wed, Mar 18, 2009 at 6:29 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12414
> ------- Comment #18 from reinette.chatre@intel.com 

FWIW, "my" patch is just removing other pre-existing patches.  We would prefer to keep all those patches and fix this issue.  Please continue to cooperate with Johannes on trying to find a fix against current 2.6.29-rc8 or later kernels.

(In reply to comment #20)
> FWIW, "my" patch is just removing other pre-existing patches.  We would
> prefer
> to keep all those patches and fix this issue.  Please continue to cooperate
> with Johannes on trying to find a fix against current 2.6.29-rc8 or later
> kernels.
> 

I am digging into this but it takes a while as I am not that familiar with the MLME. What I have found so far is that when the iwconfig command is issued with the essid then an association is indeed attempted, but because the scan information does not contain essid an association is attempted to a potentially wrong AP. This can be seen if you enable mac80211 debugging CONFIG_MAC80211_VERBOSE_DEBUG then you may see this. After this association fails it does not try again with a different AP that also matches requested connection parameters.

What the removed patch did was ensure that the scan information contains essid and the first association attempt is thus done to correct AP.

In some testing I have found that MLME does indeed at some point include essid of hidden AP in scan results ... I am currently trying to figure out how to get this done at the time of association request.

On Thu, Mar 19, 2009 at 1:03 AM,  <bugme-Please continue to cooperate
> with Johannes on trying to find a fix against current 2.6.29-rc8 or later
> kernels.

Definitely. I'm just tied up. Just compiled with debug info and will
be testing shortly.


Jeff.

Created attachment 20586 [details]
Debug patch

I have learned more about how the hidden AP stuff works and was able to verify connection to hidden AP with 2.6.28-rc8 on 4965. Could you please run a test with the attached patch to obtain more debugging about your case? Please run this together with mac80211 debugging enabled. 

This patch is on top of vanilla 2.6.28-rc8.

On Thu, Mar 19, 2009 at 7:02 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> I have learned more about how the hidden AP stuff works and was > able to
> verify connection to hidden AP with 2.6.28-rc8 on 4965.
> Could you please run a test with the attached patch to obtain
> more debugging about your case? Please run this together with
> mac80211 debugging enabled.

I'm also discovering new things.

I can now get vanilla 2.6.28-rc8 to work (7/10 times) by changing the
sequence of iwconfig.


This loop does not work at all without John's patch , but will work
100% when patched.

        iwconfig wlan0 mode Managed essid xxx key restricted xxx
        for((i = 0; i < 5; i++))
        do
                iwconfig wlan0 ap auto channel auto
                iwconfig wlan0 | grep -q "Access Point: Not-Associated"
                [ $? -ne 0 ] && break
                echo ".\c"
                sleep 1
        done


This loop only works 8 of 10 times with/without the patch.

        iwconfig wlan0 mode Managed essid xxx key restricted xxx
        iwconfig wlan0 ap auto channel auto
        for((i = 0; i < 5; i++))
        do
                iwconfig wlan0 | grep -q "Access Point: Not-Associated"
                [ $? -ne 0 ] && break
                echo ".\c"
                sleep 1
        done


The only difference is having "iwconfig wlan0 ap auto channel auto"
inside the loop.

On Thu, Mar 19, 2009 at 7:02 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> Please run
> this together with mac80211 debugging enabled.
>
> This patch is on top of vanilla 2.6.28-rc8.

Attached. Two runs

mac.fail
mac.pass

Thanks,
Jeff.

(In reply to comment #25)
> On Thu, Mar 19, 2009 at 7:02 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> > Please run
> > this together with mac80211 debugging enabled.
> >
> > This patch is on top of vanilla 2.6.28-rc8.
> 
> Attached. Two runs
> 
> mac.fail
> mac.pass
> 
> Thanks,
> Jeff.
> 

The attachments did not make it through ... perhaps it needs to be done through the web interface?

(In reply to comment #24)
> On Thu, Mar 19, 2009 at 7:02 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> > I have learned more about how the hidden AP stuff works and was > able to
> verify connection to hidden AP with 2.6.28-rc8 on 4965.
> > Could you please run a test with the attached patch to obtain
> > more debugging about your case? Please run this together with
> > mac80211 debugging enabled.
> 
> I'm also discovering new things.
> 
> I can now get vanilla 2.6.28-rc8 to work (7/10 times) by changing the
> sequence of iwconfig.
> 
> 
> This loop does not work at all without John's patch , but will work
> 100% when patched.
> 
>         iwconfig wlan0 mode Managed essid xxx key restricted xxx
>         for((i = 0; i < 5; i++))
>         do
>                 iwconfig wlan0 ap auto channel auto
>                 iwconfig wlan0 | grep -q "Access Point: Not-Associated"
>                 [ $? -ne 0 ] && break
>                 echo ".\c"
>                 sleep 1
>         done
> 
> 
> This loop only works 8 of 10 times with/without the patch.
> 
>         iwconfig wlan0 mode Managed essid xxx key restricted xxx
>         iwconfig wlan0 ap auto channel auto
>         for((i = 0; i < 5; i++))
>         do
>                 iwconfig wlan0 | grep -q "Access Point: Not-Associated"
>                 [ $? -ne 0 ] && break
>                 echo ".\c"
>                 sleep 1
>         done
> 
> 
> The only difference is having "iwconfig wlan0 ap auto channel auto"
> inside the loop.
> 

Could you please try this sequence:

iwconfig wlan0 mode Managed key restricted xxx
iwconfig wlan0 ap auto channel auto essid xxx

On Thu, Mar 19, 2009 at 11:54 PM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> Could you please try this sequence:
> iwconfig wlan0 mode Managed key restricted xxx
> iwconfig wlan0 ap auto channel auto essid xxx

This works on the command line. (Delays between commands), But putting
in a script would not work.

But, interesting discovery is that the 2nd iwconfig for "ap auto
channel auto" is not needed, and will cause it not to associate. So,
just the first iwconfig is enough to make it work.

I'm using this and it's working on 2.6.29-rc8 without patch.

modprobe iwlagn
iwconfig wlan0 essid xxx key restricted xxx
ifconfig wlan0 up


Thanks,
Jeff.

(In reply to comment #28)
> On Thu, Mar 19, 2009 at 11:54 PM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> > Could you please try this sequence:
> > iwconfig wlan0 mode Managed key restricted xxx
> > iwconfig wlan0 ap auto channel auto essid xxx
> 
> This works on the command line. (Delays between commands), But putting
> in a script would not work.

It should work. Could you please send debug log of this case? 

> 
> But, interesting discovery is that the 2nd iwconfig for "ap auto
> channel auto" is not needed, and will cause it not to associate. So,
> just the first iwconfig is enough to make it work.
> 
> I'm using this and it's working on 2.6.29-rc8 without patch.
> 
> modprobe iwlagn
> iwconfig wlan0 essid xxx key restricted xxx
> ifconfig wlan0 up
> 
> 

What if you try the following:

modprobe iwlagn
ifconfig wlan0 up
iwconfig wlan0 essid xxx key restricted xxx

(In reply to comment #28)
> 
> I'm using this and it's working on 2.6.29-rc8 without patch.
> 
> modprobe iwlagn
> iwconfig wlan0 essid xxx key restricted xxx
> ifconfig wlan0 up
> 

Considering the above comment ... can this bug be closed?

On Sat, Mar 21, 2009 at 2:51 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> Considering the above comment ... can this bug be closed?

Yes please. I've just submitted tcp dumps to Johannes, but for now,
it's all working.

Thanks,
Jeff.