iwl3945 problem with 2.6.25-rc9

iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

Hi,

Have had a look through bugzilla and not sure if any of the existing bugs
are exactly the same as mine, so thought I'd post here first to make sure
I'm not missing anything obvious.

Kernel 2.6.25-rc9 (although the same thing seems to happen on 2.6.24
kernels, so I stuck with the ipw driver and 2.6.23 til now)
Using iwl3945 firmware 2.14.1.5

Machine doesn't associate with any AP (although it does seem to see the
closer ones) and I get lots of the following errors:

iwl3945: Microcode SW error detected.  Restarting 0x82000008.

Also, and unsure if this is related or not, the mouse and keyboard behave
erratically when the iwl3945 module is loaded. Both keyboard and mouse lock
up, but store all input in a buffer and spurt it out after a few seconds.
After between 1-10 minutes the machine hangs and the Caps Lock and Scroll
Lock lights flash on and off (not the Num Lock one though).

Dmesg log is available here using netconsole on a wired connection, up to
the point where it crashes:

https://www.cs.tcd.ie/~furlongm/iwlwifi/iwlwifi-output.bz2

I also reloaded the module with debug=0x43ffb after booting, so the output
becomes more verbose at that stage.

Marcus.

RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

On , Marcus Furlong  wrote:

> Hi,
> 
> Have had a look through bugzilla and not sure if any of the
> existing bugs
> are exactly the same as mine, so thought I'd post here first
> to make sure
> I'm not missing anything obvious.
> 
> Kernel 2.6.25-rc9 (although the same thing seems to happen on 2.6.24
> kernels, so I stuck with the ipw driver and 2.6.23 til now)
> Using iwl3945 firmware 2.14.1.5
> 
> Machine doesn't associate with any AP (although it does seem to see
> the closer ones) and I get lots of the following errors:
> 
> iwl3945: Microcode SW error detected.  Restarting 0x82000008.
> 
> Also, and unsure if this is related or not, the mouse and
> keyboard behave
> erratically when the iwl3945 module is loaded. Both keyboard
> and mouse lock
> up, but store all input in a buffer and spurt it out after a
> few seconds.
> After between 1-10 minutes the machine hangs and the Caps Lock
> and Scroll
> Lock lights flash on and off (not the Num Lock one though).
> 
> Dmesg log is available here using netconsole on a wired
> connection, up to
> the point where it crashes:
> 
> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwlwifi-output.bz2
> 
> I also reloaded the module with debug=0x43ffb after booting,
> so the output
> becomes more verbose at that stage.

Looks like the device is being brought up and down a lot ... are you
perhaps running wpa_supplicant or some other user application that is
doing this? Could you please give more information about what you were
doing when these errors started to appear? 

Thank you very much for the detailed logs ... I'll pass it on to the
firmware experts.

Reinette

RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 16 April 2008 19:28 in
<D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:

> On , Marcus Furlong  wrote:
> 
>> Hi,
>> 
>> Have had a look through bugzilla and not sure if any of the
>> existing bugs
>> are exactly the same as mine, so thought I'd post here first
>> to make sure
>> I'm not missing anything obvious.
>> 
>> Kernel 2.6.25-rc9 (although the same thing seems to happen on 2.6.24
>> kernels, so I stuck with the ipw driver and 2.6.23 til now)
>> Using iwl3945 firmware 2.14.1.5
>> 
>> Machine doesn't associate with any AP (although it does seem to see
>> the closer ones) and I get lots of the following errors:
>> 
>> iwl3945: Microcode SW error detected.  Restarting 0x82000008.
>> 
>> Also, and unsure if this is related or not, the mouse and
>> keyboard behave
>> erratically when the iwl3945 module is loaded. Both keyboard
>> and mouse lock
>> up, but store all input in a buffer and spurt it out after a
>> few seconds.
>> After between 1-10 minutes the machine hangs and the Caps Lock
>> and Scroll
>> Lock lights flash on and off (not the Num Lock one though).
>> 
>> Dmesg log is available here using netconsole on a wired
>> connection, up to
>> the point where it crashes:
>> 
>> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwlwifi-output.bz2
>> 
>> I also reloaded the module with debug=0x43ffb after booting,
>> so the output
>> becomes more verbose at that stage.
> 
> Looks like the device is being brought up and down a lot ... are you
> perhaps running wpa_supplicant or some other user application that is
> doing this? Could you please give more information about what you were
> doing when these errors started to appear?

Yes, wpa_supplicant is running as part of the boot process. Should I use
some other application? (Do wireless-tools support WPA?) Or should I just
load the module on it's own and give the dmesg output from that?

Marcus.

RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Wed, 2008-04-16 at 20:01 +0100, Marcus Furlong wrote:
> On Wednesday 16 April 2008 19:28 in
> <D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.intel.com>,
> Chatre, Reinette wrote:
> 
> > On , Marcus Furlong  wrote:
> > 
> >> Hi,
> >> 
> >> Have had a look through bugzilla and not sure if any of the
> >> existing bugs
> >> are exactly the same as mine, so thought I'd post here first
> >> to make sure
> >> I'm not missing anything obvious.
> >> 
> >> Kernel 2.6.25-rc9 (although the same thing seems to happen on 2.6.24
> >> kernels, so I stuck with the ipw driver and 2.6.23 til now)
> >> Using iwl3945 firmware 2.14.1.5
> >> 
> >> Machine doesn't associate with any AP (although it does seem to see
> >> the closer ones) and I get lots of the following errors:
> >> 
> >> iwl3945: Microcode SW error detected.  Restarting 0x82000008.
> >> 
> >> Also, and unsure if this is related or not, the mouse and
> >> keyboard behave
> >> erratically when the iwl3945 module is loaded. Both keyboard
> >> and mouse lock
> >> up, but store all input in a buffer and spurt it out after a
> >> few seconds.
> >> After between 1-10 minutes the machine hangs and the Caps Lock
> >> and Scroll
> >> Lock lights flash on and off (not the Num Lock one though).
> >> 
> >> Dmesg log is available here using netconsole on a wired
> >> connection, up to
> >> the point where it crashes:
> >> 
> >> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwlwifi-output.bz2
> >> 
> >> I also reloaded the module with debug=0x43ffb after booting,
> >> so the output
> >> becomes more verbose at that stage.
> > 
> > Looks like the device is being brought up and down a lot ... are you
> > perhaps running wpa_supplicant or some other user application that is
> > doing this? Could you please give more information about what you were
> > doing when these errors started to appear?
> 
> Yes, wpa_supplicant is running as part of the boot process. Should I use
> some other application? (Do wireless-tools support WPA?) Or should I just
> load the module on it's own and give the dmesg output from that?

wpa_supplicant shouldn't be bouncing the device much.  It appears to
only bring the device up when it adds the interface (either at start
time or later via the control interface) and bring it down only when the
interface is removed (on shutdown or when removed via the control
interface).

Dan

RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 16 April 2008 20:01 in <fu5iel$c45$1@ger.gmane.org>, Marcus
Furlong wrote:

> On Wednesday 16 April 2008 19:28 in
>
<D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.intel.com>,
> Chatre, Reinette wrote:
> 
>> Looks like the device is being brought up and down a lot ... are you
>> perhaps running wpa_supplicant or some other user application that is
>> doing this? Could you please give more information about what you were
>> doing when these errors started to appear?
> 
> Yes, wpa_supplicant is running as part of the boot process. Should I use
> some other application? (Do wireless-tools support WPA?) Or should I just
> load the module on it's own and give the dmesg output from that?

Here is the output from the module loading without wpa_supplicant, then me
reloading it with debug flags, and running ifconfig wlan0 and iwlist
scanning. Still some Microcode SW and FW errors in there, but there's a lot
less noise.

https://www.cs.tcd.ie/~furlongm/iwlwifi/iwl3945-output-no-wpasupplicant.bz2

Marcus.

RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Wed, 2008-04-16 at 20:48 +0100, Marcus Furlong wrote:
> On Wednesday 16 April 2008 20:01 in <fu5iel$c45$1@ger.gmane.org>, Marcus
> Furlong wrote:
> 
> > On Wednesday 16 April 2008 19:28 in
> >
> <D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.intel.com>,
> > Chatre, Reinette wrote:
> > 
> >> Looks like the device is being brought up and down a lot ... are you
> >> perhaps running wpa_supplicant or some other user application that is
> >> doing this? Could you please give more information about what you were
> >> doing when these errors started to appear?
> > 
> > Yes, wpa_supplicant is running as part of the boot process. Should I use
> > some other application? (Do wireless-tools support WPA?) Or should I just
> > load the module on it's own and give the dmesg output from that?
> 
> Here is the output from the module loading without wpa_supplicant, then me
> reloading it with debug flags, and running ifconfig wlan0 and iwlist
> scanning. Still some Microcode SW and FW errors in there, but there's a lot
> less noise.
> 
> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwl3945-output-no-wpasupplicant.bz2

Interesting; can you run wpa_supplicant again but dump it's detailed
output using "-dddt" for us so we can see what it's doing and if it's
causing the restarts?

Dan

RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

On Wednesday, April 16, 2008 1:05 PM, Dan Williams  wrote:

> On Wed, 2008-04-16 at 20:48 +0100, Marcus Furlong wrote:
>> On Wednesday 16 April 2008 20:01 in
> <fu5iel$c45$1@ger.gmane.org>, Marcus
>> Furlong wrote:
>> 
>>> On Wednesday 16 April 2008 19:28 in
>>> 
>> 
> <D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.in
tel.com>,
>>> Chatre, Reinette wrote:
>>> 
>>>> Looks like the device is being brought up and down a lot ... are
>>>> you perhaps running wpa_supplicant or some other user application
>>>> that is doing this? Could you please give more information about
>>>> what you were doing when these errors started to appear?
>>> 
>>> Yes, wpa_supplicant is running as part of the boot process. Should
>>> I use some other application? (Do wireless-tools support WPA?) Or
>>> should I just load the module on it's own and give the dmesg output
>>> from that? 
>> 
>> Here is the output from the module loading without wpa_supplicant,
>> then me reloading it with debug flags, and running ifconfig wlan0
>> and iwlist scanning. Still some Microcode SW and FW errors in there,
>> but there's a lot less noise. 
>> 
>> 
> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwl3945-output-no-wpasu
> pplicant.bz2 
> 
> Interesting; can you run wpa_supplicant again but dump it's detailed
> output using "-dddt" for us so we can see what it's doing and if it's
> causing the restarts? 

The driver itself is responsible for many of the restarts because of the
firmware errors. A wpa_supplicant log will still be useful. 

Could you please give more information about what the system is trying
to do here? In the first log you sent most failures appear to occur when
A band channels are configured ... does this match with what you are
trying to do? Can you explain why the BSSID is all zeroes? 

Thanks

Reinette

RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 16 April 2008 22:22 in
<D936D925018D154694D8A362EEB0892004353826@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:

> On Wednesday, April 16, 2008 1:05 PM, Dan Williams  wrote:
> 
>> On Wed, 2008-04-16 at 20:48 +0100, Marcus Furlong wrote:
>>> On Wednesday 16 April 2008 20:01 in
>> <fu5iel$c45$1@ger.gmane.org>, Marcus
>>> Furlong wrote:
>>> 
>>>> On Wednesday 16 April 2008 19:28 in
>>>> 
>>> 
>>
<D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.in
> tel.com>,
>>>> Chatre, Reinette wrote:
>>>> 
>>>>> Looks like the device is being brought up and down a lot ... are
>>>>> you perhaps running wpa_supplicant or some other user application
>>>>> that is doing this? Could you please give more information about
>>>>> what you were doing when these errors started to appear?
>>>> 
>>>> Yes, wpa_supplicant is running as part of the boot process. Should
>>>> I use some other application? (Do wireless-tools support WPA?) Or
>>>> should I just load the module on it's own and give the dmesg output
>>>> from that?
>>> 
>>> Here is the output from the module loading without wpa_supplicant,
>>> then me reloading it with debug flags, and running ifconfig wlan0
>>> and iwlist scanning. Still some Microcode SW and FW errors in there,
>>> but there's a lot less noise.
>>> 
>>> 
>> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwl3945-output-no-wpasu
>> pplicant.bz2
>> 
>> Interesting; can you run wpa_supplicant again but dump it's detailed
>> output using "-dddt" for us so we can see what it's doing and if it's
>> causing the restarts?
> 
> The driver itself is responsible for many of the restarts because of the
> firmware errors. A wpa_supplicant log will still be useful.

Trying to get a wpa_supplicant log but the machine hangs reliably pretty
much every time. Got an oops over the serial cable here:

[  854.789883] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  854.792850] Modules linked in: i915 drm iwl3945 mac80211 cfg80211
intel_agp agpgart scsi_wait_scan
[  854.792850] 
[  854.792850] Pid: 9, comm: events/0 Not tainted (2.6.25-rc9 #2)
[  854.792850] EIP: 0060:[<c039e62f>] EFLAGS: 00010093 CPU: 0
[  854.792850] EIP is at alps_process_byte+0x1f/0x80
[  854.792850] EAX: 00000000 EBX: f73e2280 ECX: f68de400 EDX: 00000000
[  854.792850] ESI: f68de400 EDI: f722a400 EBP: c0652f2c ESP: c0652f28
[  854.792850]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[  854.792850] Process events/0 (pid: 9, ti=c0652000 task=f787e000
task.ti=f7854000)
[  854.792850] Stack: f68de400 c0652f48 c039baef 00000000 00000002 00000001
c0391d71 00000000 
[  854.792850]        c0652f70 c039c378 00000000 c0652f70 c047a00a 00000000
00000002 f722a400 
[  854.792850]        c05c8560 00000000 c0652f90 c0391d89 00000092 f722a44c
00000096 00000000 
[  854.792850] Call Trace:
[  854.792850]  [<c039baef>] ? psmouse_handle_byte+0xf/0x110
[  854.792850]  [<c0391d71>] ? serio_interrupt+0x21/0x80
[  854.792850]  [<c039c378>] ? psmouse_interrupt+0xc8/0x2a0
[  854.792850]  [<c047a00a>] ? _spin_lock_irqsave+0x4a/0x60
[  854.792850]  [<c0391d89>] ? serio_interrupt+0x39/0x80
[  854.792850]  [<c0392a69>] ? i8042_interrupt+0x109/0x250
[  854.792850]  [<c0157c78>] ? handle_IRQ_event+0x28/0x60
[  854.792850]  [<c01590d3>] ? handle_edge_irq+0xb3/0x140
[  854.792850]  [<c0159020>] ? handle_edge_irq+0x0/0x140
[  854.792850]  [<c010738b>] ? do_IRQ+0x8b/0xf0
[  854.792850]  [<c0104c12>] ? common_interrupt+0x2e/0x34
[  854.792850]  [<c01400d8>] ? posix_cpu_timer_set+0x368/0x430
[  854.792850]  [<c047a3a7>] ? _spin_unlock_irqrestore+0x57/0x70
[  854.792850]  [<c01340b7>] ? __mod_timer+0xa7/0xc0
[  854.792850]  [<c013b2d4>] ? queue_delayed_work_on+0x84/0xc0
[  854.792850]  [<c013b4e1>] ? queue_delayed_work+0x51/0x60
[  854.792850]  [<c013b51a>] ? schedule_delayed_work+0x2a/0x40
[  854.792850]  [<c0168089>] ? vmstat_update+0x39/0x50
[  854.792850]  [<c013aa6c>] ? run_workqueue+0x12c/0x1e0
[  854.792850]  [<c013aa14>] ? run_workqueue+0xd4/0x1e0
[  854.792850]  [<c047a389>] ? _spin_unlock_irqrestore+0x39/0x70
[  854.792850]  [<c0168050>] ? vmstat_update+0x0/0x50
[  854.792850]  [<c013b5c9>] ? worker_thread+0x99/0xf0
[  854.792850]  [<c013e250>] ? autoremove_wake_function+0x0/0x50
[  854.792850]  [<c013b530>] ? worker_thread+0x0/0xf0
[  854.792850]  [<c013df62>] ? kthread+0x42/0x70
[  854.792850]  [<c013df20>] ? kthread+0x0/0x70
[  854.792850]  [<c0104e97>] ? kernel_thread_helper+0x7/0x10
[  854.792850]  =======================
[  854.792850] Code: b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 c1 89 e5 53
0f b6 90 a0 00 00 00 8b 18 0f b6 c2 25 c8 00 00 00 83 f8 08 74 37 8b 43 24
<22> 50 04 3a 50 03 74 09 5b 31 c0 5d c3 8d 74 26 00 0f b6 91 a9 
[  854.792850] EIP: [<c039e62f>] alps_process_byte+0x1f/0x80 SS:ESP
0068:c0652f28

I guess this is what's causing the jerkiness of the mouse/keyboard.

> Could you please give more information about what the system is trying
> to do here? In the first log you sent most failures appear to occur when
> A band channels are configured ... does this match with what you are
> trying to do? Can you explain why the BSSID is all zeroes?

I have no idea why the BSSID is all zeros. This usually happens first thing
after boot, even with the ipw driver. I usually use wpa_gui to select the
second network in my wpa_supplicant list (which is not actually present at
my current location), then reselect the first network (which is present).
It usually then associates. That's with the ipw driver, so I was seeing if
the same trick would work with the iwl driver (in the first log). Not sure
what "A band channels" means, can you explain that and possibly I can
answer..

Marcus.

RE: RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

On , Marcus Furlong  wrote:

> On Wednesday 16 April 2008 22:22 in
> <D936D925018D154694D8A362EEB0892004353826@orsmsx416.amr.corp.in
> tel.com>, Chatre, Reinette wrote:
> 

> Trying to get a wpa_supplicant log but the machine hangs
> reliably pretty
> much every time. Got an oops over the serial cable here:
> 
> [  854.789883] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [  854.792850] Modules linked in: i915 drm iwl3945 mac80211 cfg80211
> intel_agp agpgart scsi_wait_scan
> [  854.792850]
> [  854.792850] Pid: 9, comm: events/0 Not tainted (2.6.25-rc9 #2)
> [  854.792850] EIP: 0060:[<c039e62f>] EFLAGS: 00010093 CPU: 0
> [  854.792850] EIP is at alps_process_byte+0x1f/0x80
> [  854.792850] EAX: 00000000 EBX: f73e2280 ECX: f68de400 EDX: 00000000
> [  854.792850] ESI: f68de400 EDI: f722a400 EBP: c0652f2c ESP: c0652f28
> [  854.792850]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> [  854.792850] Process events/0 (pid: 9, ti=c0652000 task=f787e000
> task.ti=f7854000) [  854.792850] Stack: f68de400 c0652f48 c039baef
> 00000000 00000002 00000001 c0391d71 00000000
> [  854.792850]        c0652f70 c039c378 00000000 c0652f70
> c047a00a 00000000
> 00000002 f722a400
> [  854.792850]        c05c8560 00000000 c0652f90 c0391d89 00000092
> f722a44c 00000096 00000000
> [  854.792850] Call Trace:
> [  854.792850]  [<c039baef>] ? psmouse_handle_byte+0xf/0x110
> [  854.792850]  [<c0391d71>] ? serio_interrupt+0x21/0x80
> [  854.792850]  [<c039c378>] ? psmouse_interrupt+0xc8/0x2a0
> [  854.792850]  [<c047a00a>] ? _spin_lock_irqsave+0x4a/0x60
> [  854.792850]  [<c0391d89>] ? serio_interrupt+0x39/0x80
> [  854.792850]  [<c0392a69>] ? i8042_interrupt+0x109/0x250
> [  854.792850]  [<c0157c78>] ? handle_IRQ_event+0x28/0x60
> [  854.792850]  [<c01590d3>] ? handle_edge_irq+0xb3/0x140
> [  854.792850]  [<c0159020>] ? handle_edge_irq+0x0/0x140
> [  854.792850]  [<c010738b>] ? do_IRQ+0x8b/0xf0
> [  854.792850]  [<c0104c12>] ? common_interrupt+0x2e/0x34
> [  854.792850]  [<c01400d8>] ? posix_cpu_timer_set+0x368/0x430
> [  854.792850]  [<c047a3a7>] ? _spin_unlock_irqrestore+0x57/0x70
> [  854.792850]  [<c01340b7>] ? __mod_timer+0xa7/0xc0
> [  854.792850]  [<c013b2d4>] ? queue_delayed_work_on+0x84/0xc0
> [  854.792850]  [<c013b4e1>] ? queue_delayed_work+0x51/0x60
> [  854.792850]  [<c013b51a>] ? schedule_delayed_work+0x2a/0x40
> [  854.792850]  [<c0168089>] ? vmstat_update+0x39/0x50
> [  854.792850]  [<c013aa6c>] ? run_workqueue+0x12c/0x1e0
> [  854.792850]  [<c013aa14>] ? run_workqueue+0xd4/0x1e0
> [  854.792850]  [<c047a389>] ? _spin_unlock_irqrestore+0x39/0x70
> [  854.792850]  [<c0168050>] ? vmstat_update+0x0/0x50
> [  854.792850]  [<c013b5c9>] ? worker_thread+0x99/0xf0
> [  854.792850]  [<c013e250>] ? autoremove_wake_function+0x0/0x50
> [  854.792850]  [<c013b530>] ? worker_thread+0x0/0xf0
> [  854.792850]  [<c013df62>] ? kthread+0x42/0x70
> [  854.792850]  [<c013df20>] ? kthread+0x0/0x70
> [  854.792850]  [<c0104e97>] ? kernel_thread_helper+0x7/0x10
> [  854.792850]  =======================
> [  854.792850] Code: b6 00 00 00 00 8d bc 27 00 00 00 00 55 89
> c1 89 e5 53
> 0f b6 90 a0 00 00 00 8b 18 0f b6 c2 25 c8 00 00 00 83 f8 08 74 37 8b
> 43 24 <22> 50 04 3a 50 03 74 09 5b 31 c0 5d c3 8d 74 26 00 0f b6 91 a9
> [  854.792850] EIP: [<c039e62f>] alps_process_byte+0x1f/0x80 SS:ESP
> 0068:c0652f28 
> 
> I guess this is what's causing the jerkiness of the mouse/keyboard.

I don't know what to say about the above ... it seems to be a different
problem.

> 
>> Could you please give more information about what the system is
>> trying to do here? In the first log you sent most failures appear to
>> occur when A band channels are configured ... does this match with
>> what you are trying to do? Can you explain why the BSSID is all
>> zeroes? 
> 
> I have no idea why the BSSID is all zeros. This usually
> happens first thing
> after boot, even with the ipw driver. I usually use wpa_gui to
> select the
> second network in my wpa_supplicant list (which is not
> actually present at
> my current location), then reselect the first network (which
> is present).

Can you send a copy of your wpa_supplicant configuration file (comment
out the private parts)?

> It usually then associates. That's with the ipw driver, so I
> was seeing if
> the same trick would work with the iwl driver (in the first
> log). 

There seems to be a lot going on through initialization scripts of your
distribution. Could you disable all that and try to get up and running
with as little variables as possible? It may be that the interface is
automatically brought up when the module is loaded - this script should
be among your network init scripts. Can you disable that? You can load
the driver with debugging and see through the logs if anything is trying
to use it. The first goal is to load the driver and not have it do any
work after initial load.

After this follow the following steps (I am assuming you are not using
security):
$ /sbin/ip link set dev wlan0 up 
$ iwlist wlan0 scan
Search for your AP in the above output - should match with your
wpa_supplicant conf file.
$ iwconfig wlan0 channel <channel of your AP> ap <MAC of your AP> essid
<essid of your AP> 
$ iwconfig
check above output to see if you are associated
next use your usual net app to get an IP (dhclient?)

Can you associate with the above steps? What do the logs look like? 

> Not sure
> what "A band channels" means, can you explain that and possibly I can
> answer.. 

A band operates at 5GHz as opposed to B and G that operates in 2.4GHz.
Do you know what your AP is configured as?

Reinette

RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 16 April 2008 22:22 in
<D936D925018D154694D8A362EEB0892004353826@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:

> On Wednesday, April 16, 2008 1:05 PM, Dan Williams  wrote:
> 
>> On Wed, 2008-04-16 at 20:48 +0100, Marcus Furlong wrote:
>>> On Wednesday 16 April 2008 20:01 in
>> <fu5iel$c45$1@ger.gmane.org>, Marcus
>>> Furlong wrote:
>>> 
>>>> On Wednesday 16 April 2008 19:28 in
>>>> 
>>> 
>>
<D936D925018D154694D8A362EEB08920043535A1@orsmsx416.amr.corp.in
> tel.com>,
>>>> Chatre, Reinette wrote:
>>>> 
>>>>> Looks like the device is being brought up and down a lot ... are
>>>>> you perhaps running wpa_supplicant or some other user application
>>>>> that is doing this? Could you please give more information about
>>>>> what you were doing when these errors started to appear?
>>>> 
>>>> Yes, wpa_supplicant is running as part of the boot process. Should
>>>> I use some other application? (Do wireless-tools support WPA?) Or
>>>> should I just load the module on it's own and give the dmesg output
>>>> from that?
>>> 
>>> Here is the output from the module loading without wpa_supplicant,
>>> then me reloading it with debug flags, and running ifconfig wlan0
>>> and iwlist scanning. Still some Microcode SW and FW errors in there,
>>> but there's a lot less noise.
>>> 
>>> 
>> https://www.cs.tcd.ie/~furlongm/iwlwifi/iwl3945-output-no-wpasu
>> pplicant.bz2
>> 
>> Interesting; can you run wpa_supplicant again but dump it's detailed
>> output using "-dddt" for us so we can see what it's doing and if it's
>> causing the restarts?
> 
> The driver itself is responsible for many of the restarts because of the
> firmware errors. A wpa_supplicant log will still be useful.

Ok got one now:

https://www.cs.tcd.ie/~furlongm/iwlwifi/minicom-wpa_supplicant-output

Reloaded the module halfway through to see if that made any difference.
Sometimes it sees some of the access points after rmmod-ing and
modprobe-ing it (never sees as many as the ipw driver though), but this
time it didn't make any difference.

Marcus.

RE: RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 16 April 2008 23:55 in
<D936D925018D154694D8A362EEB08920043539AE@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:

> On , Marcus Furlong  wrote:
> 
>> On Wednesday 16 April 2008 22:22 in
>>
<D936D925018D154694D8A362EEB0892004353826@orsmsx416.amr.corp.in
>> tel.com>, Chatre, Reinette wrote:
>> 

[SNIP]

>>> Could you please give more information about what the system is
>>> trying to do here? In the first log you sent most failures appear to
>>> occur when A band channels are configured ... does this match with
>>> what you are trying to do? Can you explain why the BSSID is all
>>> zeroes?
>> 
>> I have no idea why the BSSID is all zeros. This usually
>> happens first thing
>> after boot, even with the ipw driver. I usually use wpa_gui to
>> select the
>> second network in my wpa_supplicant list (which is not
>> actually present at
>> my current location), then reselect the first network (which
>> is present).
> 
> Can you send a copy of your wpa_supplicant configuration file (comment
> out the private parts)?

https://www.cs.tcd.ie/~furlongm/iwlwifi/wpa_supplicant.conf

> 
>> It usually then associates. That's with the ipw driver, so I
>> was seeing if
>> the same trick would work with the iwl driver (in the first
>> log).
> 
> There seems to be a lot going on through initialization scripts of your
> distribution. Could you disable all that and try to get up and running
> with as little variables as possible? It may be that the interface is
> automatically brought up when the module is loaded - this script should
> be among your network init scripts. Can you disable that? You can load
> the driver with debugging and see through the logs if anything is trying
> to use it. The first goal is to load the driver and not have it do any
> work after initial load.

The second log I linked to was made similar to the above scenario. The
module autoloads but I disabled the network script on boot. Then I rmmod-ed
the iwl3945 module and loaded it again with debugging enabled. After no
more kernel messages were being outputted, I ran wpa_supplicant in the
foreground from the command line.

> After this follow the following steps (I am assuming you are not using
> security):
> $ /sbin/ip link set dev wlan0 up
> $ iwlist wlan0 scan
> Search for your AP in the above output - should match with your
> wpa_supplicant conf file.

This works, not always the first time, but eventually it finds my AP.
Sometimes it takes up to ten minutes to find my AP even though it's in the
same room as me.

> $ iwconfig wlan0 channel <channel of your AP> ap <MAC of your AP> essid
> <essid of your AP>
> $ iwconfig
> check above output to see if you are associated
> next use your usual net app to get an IP (dhclient?)
> 
> Can you associate with the above steps? What do the logs look like?

Unfortunately the AP is configured to use WPA-PSK and there are others
connected at the moment so I can't test if it connects without security.
I'll have a go at associating using WPA with the latest version of
wireless-tools.

> 
>> Not sure
>> what "A band channels" means, can you explain that and possibly I can
>> answer..
> 
> A band operates at 5GHz as opposed to B and G that operates in 2.4GHz.
> Do you know what your AP is configured as?

Ok thanks, I know what you mean now. The AP is configured to operate using
band G only.

Marcus.

RE: RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 16 April 2008 23:55 in
<D936D925018D154694D8A362EEB08920043539AE@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:

> There seems to be a lot going on through initialization scripts of your
> distribution. Could you disable all that and try to get up and running
> with as little variables as possible? It may be that the interface is
> automatically brought up when the module is loaded - this script should
> be among your network init scripts. Can you disable that? You can load
> the driver with debugging and see through the logs if anything is trying
> to use it. The first goal is to load the driver and not have it do any
> work after initial load.

Ok, I did this now. iwl3945 is now only loaded manually by modprobe, and the
initscript is disabled for wlan0.

> After this follow the following steps (I am assuming you are not using
> security):
> $ /sbin/ip link set dev wlan0 up
> $ iwlist wlan0 scan
> Search for your AP in the above output - should match with your
> wpa_supplicant conf file.
> $ iwconfig wlan0 channel <channel of your AP> ap <MAC of your AP> essid
> <essid of your AP>
> $ iwconfig
> check above output to see if you are associated
> next use your usual net app to get an IP (dhclient?)
> 
> Can you associate with the above steps? What do the logs look like?

The dmesg output is here:

https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-wirelesstools-only

iwconfig wlan0 said it was associated (connecting to the AP with no security
now):

wlan0     IEEE 802.11g  ESSID:"testing"
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:0F:CC:5E:86:00
          Bit Rate=54 Mb/s   Tx-Power=15 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:off
          Link Quality=84/100  Signal level=-49 dBm  Noise level=-88 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


but it never got an IP address, no matter what timeout I set for the dhcp
client.

iwlist wlan0 scan showed the AP a few times, but mostly found nothing at
all. When it did find APs, it found at most 2-3 APs, whereas the ipw driver
finds 10 or more APs on the same machine.

Marcus.

RE: RE: RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On , Marcus Furlong  wrote:

> iwlist wlan0 scan showed the AP a few times, but mostly found nothing
> at all. When it did find APs, it found at most 2-3 APs, whereas
> the ipw driver
> finds 10 or more APs on the same machine.

I am seeing something very strange in this log and the logs you sent in
your first message. It appears that your driver uses software scanning
while hardware scanning is the default for this driver. This appears to
be the cause of the ucode errors as the A band channels are configured
as part of the scanning process.

Now, how this happens is weird. I tried running 2.6.25-rc9 myself and
was not able to reproduce the problem - hardware scanning was used.  The
driver is also explicit when HW scanning is disabled, this does not
appear in your logs, it is also explicit about when it runs HW scanning,
this also does not appear in your logs. So it does not seem as though
you are disabling the default HW scanning, but yet it uses SW scanning.
How it ends up using software scanning is not clear.

In an effort to trace what could be happening I created a small patch
(attached) that adds more debugging to the scanning code. Could you
please run with this patch and send us the debug output? 

Thank you very much

Reinette









[-- Attachment #2: scan.patch --]
[-- Type: application/octet-stream, Size: 812 bytes --]

diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index c170685..b9ca6a1 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -3317,16 +3317,22 @@ static int ieee80211_sta_start_scan(struct net_device *dev,
 		return -EBUSY;
 	}
 
+	dump_stack();
+	printk(KERN_DEBUG "Testing if driver's hw scanning enabled ...\n");
 	if (local->ops->hw_scan) {
+		printk(KERN_DEBUG "Driver provided hw_scan function ... \n");
 		int rc = local->ops->hw_scan(local_to_hw(local),
 					     ssid, ssid_len);
 		if (!rc) {
+			printk(KERN_DEBUG "Driver's hw_scan function SUCCESS... \n");
 			local->sta_hw_scanning = 1;
 			local->scan_dev = dev;
 		}
 		return rc;
 	}
 
+	printk(KERN_DEBUG "Using software scanning ...\n");
+
 	local->sta_sw_scanning = 1;
 
 	rcu_read_lock();

RE: RE: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]


> > iwlist wlan0 scan showed the AP a few times, but mostly found nothing
> > at all. When it did find APs, it found at most 2-3 APs, whereas
> > the ipw driver
> > finds 10 or more APs on the same machine.
> 
> I am seeing something very strange in this log and the logs you sent in
> your first message. It appears that your driver uses software scanning
> while hardware scanning is the default for this driver. This appears to
> be the cause of the ucode errors as the A band channels are configured
> as part of the scanning process.

Just jumping in here because I want to know if there are any mac80211
bugs (I don't have any 5 GHz hw except the iwl4965, no AP), would it
maybe help to explicitly enable sw scanning?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

RE: RE: RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

On Friday, April 18, 2008 2:57 PM, Johannes Berg  wrote:

 
> Just jumping in here because I want to know if there are any mac80211
> bugs (I don't have any 5 GHz hw except the iwl4965, no AP), would it
> maybe help to explicitly enable sw scanning?

First thing is that there is a iwlwifi driver or ucode problem as it
asserts every time (it seems) when mac_config is called for channels 38,
42, 46, and 52. Channel 36 succeeds. The cause of the ucode error is
unclear to me as I am waiting for somebody to get back to me about what
the contents of that "event log dump" means.

I looked further about why mac_config is called for those channels and
the reason appears to be that it is done from ieee80211_sta_scan_work.
This should not happen as it should only do so for sw scanning (if I
understand correctly), while the default for this driver is hw scanning
(and the user is not overriding the default). I am thus now trying to
figure out how it actually thinks sw scanning is enabled through some
simple debugging where mac80211 tries to run the driver's hw_scan
function.

Explicitly enabling sw scanning is an interesting idea. 

Marcus: could you please run your test twice with that patch? The first
time you run it as you did before, the second time please provide the
driver parameter "disable_hw_scan=1" together with the debug parameter.

Thank you 

Reinette

Re: RE: iwl3945 problem with 2.6.25-rc9

[Brian Morrison]

On Fri, 18 Apr 2008 15:12:13 -0700
"Chatre, Reinette" <reinette.chatre@intel.com> wrote:

> Explicitly enabling sw scanning is an interesting idea. 
> 
> Marcus: could you please run your test twice with that patch? The first
> time you run it as you did before, the second time please provide the
> driver parameter "disable_hw_scan=1" together with the debug parameter.

Not wishing to muddy the waters, but I've found that the iwlwifi driver
with a 3945 card is only reliable for scanning and associating for
my laptop (x86_64) with disable_hw_scan=1 set, this is with
2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.

Previous to the recent heavy driver development, with 2.6.23.15-137.fc8
the opposite was the case. This was driver version 1.2.23.

Currently with sw scanning *every* scan returns my own 2 APs, whereas
using hw scanning I often receive "No scan results" and my 2 APs
sometimes appear in the scan output and disappear frequently. It's
equally unreliable when I can see my neighbours APs, the software scan
is reliable when signals are strong enough to register at all.

One of the Fedora common bugs advised the used of sw scanning, this is
still showing up on the common bugs list.

-- 

Brian Morrison

   "Arguing with an engineer is like wrestling with a pig in the mud;
    after a while you realize you are muddy and the pig is enjoying it."

RE: RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

On , Brian Morrison  wrote:

> Not wishing to muddy the waters, but I've found that the iwlwifi
> driver with a 3945 card is only reliable for scanning and associating
> for 
> my laptop (x86_64) with disable_hw_scan=1 set, this is with
> 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.

I agree that your problem is related (no scanning results from driver),
but it does seem to be different from what we are trying to debug here.
In this case the user is not receiving scanning results when using sw
scanning while the driver should have been using hw scanning because the
user is not using that driver parameter as you are.

Reinette

Re: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]


> Not wishing to muddy the waters, but I've found that the iwlwifi driver
> with a 3945 card is only reliable for scanning and associating for
> my laptop (x86_64) with disable_hw_scan=1 set, this is with
> 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
> 
> Previous to the recent heavy driver development, with 2.6.23.15-137.fc8
> the opposite was the case. This was driver version 1.2.23.
> 
> Currently with sw scanning *every* scan returns my own 2 APs, whereas
> using hw scanning I often receive "No scan results" and my 2 APs
> sometimes appear in the scan output and disappear frequently. It's
> equally unreliable when I can see my neighbours APs, the software scan
> is reliable when signals are strong enough to register at all.

What I've found (a long time ago with hostapd) is that some APs are slow
and the firmware-assisted scanning has a too small dwell period. Maybe
we should have a module option for that so we can ask people to change
that in such cases? You could try to change the IWL_ACTIVE_DWELL_TIME_24
(and/or IWL_ACTIVE_DWELL_TIME_52) to higher values and maybe setting
IWL_PLCP_QUIET_THRESH to 0.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: iwl3945 problem with 2.6.25-rc9

[Brian Morrison]

On Fri, 18 Apr 2008 15:35:21 -0700
"Chatre, Reinette" <reinette.chatre@intel.com> wrote:

> On , Brian Morrison  wrote:
> 
> > Not wishing to muddy the waters, but I've found that the iwlwifi
> > driver with a 3945 card is only reliable for scanning and associating
> > for 
> > my laptop (x86_64) with disable_hw_scan=1 set, this is with
> > 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
> 
> I agree that your problem is related (no scanning results from driver),
> but it does seem to be different from what we are trying to debug here.
> In this case the user is not receiving scanning results when using sw
> scanning while the driver should have been using hw scanning because the
> user is not using that driver parameter as you are.

Yes, I just thought it might be useful to know that some people are
seeing the exact reverse.

It's actually working well for me now, so I'm in no hurry to break it :)

-- 

Brian Morrison

bdm at fenrir dot org dot uk

   "Arguing with an engineer is like wrestling with a pig in the mud;
    after a while you realize you are muddy and the pig is enjoying it."
    
GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html

Re: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Sat, 2008-04-19 at 00:37 +0200, Johannes Berg wrote:

> What I've found (a long time ago with hostapd) is that some APs are slow
> and the firmware-assisted scanning has a too small dwell period. Maybe
> we should have a module option for that so we can ask people to change
> that in such cases? You could try to change the IWL_ACTIVE_DWELL_TIME_24
> (and/or IWL_ACTIVE_DWELL_TIME_52) to higher values and maybe setting
> IWL_PLCP_QUIET_THRESH to 0.

Just as a datapoint, mac80211's sw scanning uses about 30 msec for
active and 200 for passive (on both bands).

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: RE: iwl3945 problem with 2.6.25-rc9

[Tomas Winkler]

On Sat, Apr 19, 2008 at 1:39 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sat, 2008-04-19 at 00:37 +0200, Johannes Berg wrote:
>
>  > What I've found (a long time ago with hostapd) is that some APs are slow
>  > and the firmware-assisted scanning has a too small dwell period. Maybe
>  > we should have a module option for that so we can ask people to change
>  > that in such cases? You could try to change the IWL_ACTIVE_DWELL_TIME_24
>  > (and/or IWL_ACTIVE_DWELL_TIME_52) to higher values and maybe setting
>  > IWL_PLCP_QUIET_THRESH to 0.
>
>  Just as a datapoint, mac80211's sw scanning uses about 30 msec for
>  active and 200 for passive (on both bands).
>
First of all we have some scanning fixes coming soon
Second the 3954 and 4965 my uCode may crash intentionally if you send
probe requests on a passive channel.according EEPROM.
I personally  wish to not make SW scanning possible at all for that reason.
Third the scanning on passive channels is a bit conservative we need
to changed that in the FW.
At last iwlwifi HW scanning can handle up to 4 essids for direct scan
but currently wireless tools interface cannot utilize this.

Tomas


>  johannes
>

RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Fri, 18 Apr 2008 15:12:13 -0700, you wrote:
>
> On Friday, April 18, 2008 2:57 PM, Johannes Berg wrote:
>
>> Just jumping in here because I want to know if there are any mac8021=
1
>> bugs (I don't have any 5 GHz hw except the iwl4965, no AP), would it
>> maybe help to explicitly enable sw scanning?
>
> First thing is that there is a iwlwifi driver or ucode problem as it
> asserts every time (it seems) when mac_config is called for channels =
38,
> 42, 46, and 52. Channel 36 succeeds. The cause of the ucode error is
> unclear to me as I am waiting for somebody to get back to me about wh=
at
> the contents of that "event log dump" means.
>
> I looked further about why mac_config is called for those channels an=
d
> the reason appears to be that it is done from ieee80211_sta_scan_work=
=2E
> This should not happen as it should only do so for sw scanning (if I
> understand correctly), while the default for this driver is hw scanni=
ng
> (and the user is not overriding the default). I am thus now trying to
> figure out how it actually thinks sw scanning is enabled through some
> simple debugging where mac80211 tries to run the driver's hw_scan
> function.
>
> Explicitly enabling sw scanning is an interesting idea.
>
> Marcus: could you please run your test twice with that patch? The fir=
st
> time you run it as you did before, the second time please provide the
> driver parameter "disable_hw_scan=3D1" together with the debug parame=
ter.

Both dmesg logs here:

https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch-disable=
_hw_scan

This time I was able to associate, and the dhcp client got an address e=
ach time (with and without disable_hwscan=3D1). However, with disable_h=
w_scan=3D1, I tried to associate, then dmesg said it had timed out. Aft=
er playing around a bit, I figured out that I could only properly assoc=
iate with my AP (essid testing) after I associated with a different AP =
(connected to my neighbours one). Rebooted a few times and repeated and=
 it worked each time.

Unfortunately both with and without disable_hwscan=3D1, I lost the conn=
ection after a few minutes.

(Quick question: I can't find information about using wireless-tools an=
d wpa for this driver. I saw for other drivers they use iwpriv set_algo=
=3D2 for wpa support, but iwl3945 doesn't seem to support this yet or i=
s there a different way?)

Marcus.
_________________________________________________________________
Love Hotmail? It just got better =96 Drag and Drop capabilities, new Re=
ading Panes making it easier to read your mail, enhanced security setti=
ngs, 5GB of FREE storage? New Windows Live Hotmail. Get your free accou=
nt here
http://get.live.com/mail/overview/--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]


> Second the 3954 and 4965 my uCode may crash intentionally if you send
> probe requests on a passive channel.according EEPROM.

I really wonder what sort of error handling strategy that is, even if
it's done for regulatory compliance purposes I don't see a need to crash
the whole card. Especially considering that the userspace MLME in
wpa_supplicant will scan by itself (yes, it scans in userspace, whether
or not you may like that), of course it would be made comply with
regulatory settings but that makes it hard to develop.

> I personally  wish to not make SW scanning possible at all for that reason.

That is not going to happen since you can always "scan" by sending probe
requests manually.

> At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> but currently wireless tools interface cannot utilize this.

Does anybody actually *want* that? I personally dislike the behaviour of
scanning for all previously known SSIDs actively when hidden SSIDs are
so uncommon, I see it as an information disclosure vulnerability.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: RE: iwl3945 problem with 2.6.25-rc9

[Vincent C Jones]

On Sat, 2008-04-19 at 10:32 +0200, Johannes Berg wrote:
> > At last iwlwifi HW scanning can handle up to 4 essids for direct
> > scan but currently wireless tools interface cannot utilize this.
> 
> Does anybody actually *want* that? I personally dislike the behaviour
> of scanning for all previously known SSIDs actively when hidden SSIDs
> are so uncommon, I see it as an information disclosure vulnerability.

I can't speak for what others may want, but the Payment Card Industry
security guidelines include not broadcasting the SSID as one of their
requirements, if that is what you mean by "hidden SSIDs." 
-- 
Vincent C Jones <v.jones@networkingunlimited.com>
Networking Unlimited, Inc.

Re: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


> > Does anybody actually *want* that? I personally dislike the behaviour
> > of scanning for all previously known SSIDs actively when hidden SSIDs
> > are so uncommon, I see it as an information disclosure vulnerability.
> 
> I can't speak for what others may want, but the Payment Card Industry
> security guidelines include not broadcasting the SSID as one of their
> requirements, if that is what you mean by "hidden SSIDs." 

So how would you feel if I told you that, after you have once used that
hiddent network, your laptop will be broadcasting the SSID in probe
requests every time it scans, no matter where you are, even if you've
moved across the continent?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: RE: iwl3945 problem with 2.6.25-rc9

[Vincent C Jones]

On Sat, 2008-04-19 at 15:09 +0200, Johannes Berg wrote:
> > > Does anybody actually *want* that? I personally dislike the behaviour
> > > of scanning for all previously known SSIDs actively when hidden SSIDs
> > > are so uncommon, I see it as an information disclosure vulnerability.
> > 
> > I can't speak for what others may want, but the Payment Card Industry
> > security guidelines include not broadcasting the SSID as one of their
> > requirements, if that is what you mean by "hidden SSIDs." 
> 
> So how would you feel if I told you that, after you have once used that
> hidden network, your laptop will be broadcasting the SSID in probe
> requests every time it scans, no matter where you are, even if you've
> moved across the continent?

I am not going to waste bandwidth debating the correctness of the PCI
guidelines, because right or wrong, they are what they are. I was just
trying to point out that the need to deal with access points which do
not broadcast their SSIDs is real and likely to become more common in
the future, at least for any systems using wireless in a retail or other
credit card dealing environment.

I'll leave it up to you (collective you, not necessarily a personal
you), how to best deal with associating with APs which are not
broadcasting their SSIDs. I agree with you (personal you this time) that
roaming around the country broadcasting those SSIDs does not seem
particularly desirable. So how should the ability to connect to non SSID
broadcasting APs be implemented? 

My hope is that the more you are aware of the constraints on others who
want to take advantage of all your hard work, the more likely you are to
make the correct decisions and trade offs. I am not attacking your
efforts, ability or motivation. I only wanted to point out that the
design assumption in the first quotation that "hidden SSIDs are so
uncommon" may need to be revised.
-- 
Vincent C Jones <v.jones@networkingunlimited.com>
Networking Unlimited, Inc.

Re: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]


> > So how would you feel if I told you that, after you have once used that
> > hidden network, your laptop will be broadcasting the SSID in probe
> > requests every time it scans, no matter where you are, even if you've
> > moved across the continent?
> 
> I am not going to waste bandwidth debating the correctness of the PCI
> guidelines, because right or wrong, they are what they are. I was just
> trying to point out that the need to deal with access points which do
> not broadcast their SSIDs is real and likely to become more common in
> the future, at least for any systems using wireless in a retail or other
> credit card dealing environment.

Oh, I don't want to debate the PCI guidelines, just saying that, which
is what I started out with, I don't see much reason to have active
scanning for four SSIDs.

> I'll leave it up to you (collective you, not necessarily a personal
> you), how to best deal with associating with APs which are not
> broadcasting their SSIDs. I agree with you (personal you this time) that
> roaming around the country broadcasting those SSIDs does not seem
> particularly desirable. So how should the ability to connect to non SSID
> broadcasting APs be implemented? 

I would probably list, in network-manager, "I found (a) hidden
network(s)" and ask the user for an SSID to scan for actively at that
particular time, rather than trying to scan for all previously known
SSIDs even if those networks weren't hidden, as windows laptops (at
least those with Intel hardware but I haven't seen many others) seem to
do.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: RE: iwl3945 problem with 2.6.25-rc9

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]


> > I'll leave it up to you (collective you, not necessarily a personal
> > you), how to best deal with associating with APs which are not
> > broadcasting their SSIDs. I agree with you (personal you this time) that
> > roaming around the country broadcasting those SSIDs does not seem
> > particularly desirable. So how should the ability to connect to non SSID
> > broadcasting APs be implemented? 
> 
> I would probably list, in network-manager, "I found (a) hidden
> network(s)" and ask the user for an SSID to scan for actively at that
> particular time, rather than trying to scan for all previously known
> SSIDs even if those networks weren't hidden, as windows laptops (at
> least those with Intel hardware but I haven't seen many others) seem to
> do.

Or it could remember the BSSID and when it encounters the BSSID again
scan it actively to see if it still has the same (albeit hidden) SSID.

My N810 behaves that way too, incidentally, it seems to first scan
broadcast but if you then don't select a network quickly it starts
scanning all networks directedly that it has previously saved.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Sat, 2008-04-19 at 15:09 +0200, Johannes Berg wrote:
> > > Does anybody actually *want* that? I personally dislike the behaviour
> > > of scanning for all previously known SSIDs actively when hidden SSIDs
> > > are so uncommon, I see it as an information disclosure vulnerability.
> > 
> > I can't speak for what others may want, but the Payment Card Industry
> > security guidelines include not broadcasting the SSID as one of their
> > requirements, if that is what you mean by "hidden SSIDs." 
> 
> So how would you feel if I told you that, after you have once used that
> hiddent network, your laptop will be broadcasting the SSID in probe
> requests every time it scans, no matter where you are, even if you've
> moved across the continent?

Unfortuately, I keep getting way too many reports about hidden SSIDs
still.  I don't feel like it's something we can start ignoring (yet).
Maybe in a few years, but we've still got to handle this for the
forseeable future.

Dan

Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Fri, 2008-04-18 at 23:23 +0100, Brian Morrison wrote:
> On Fri, 18 Apr 2008 15:12:13 -0700
> "Chatre, Reinette" <reinette.chatre@intel.com> wrote:
> 
> > Explicitly enabling sw scanning is an interesting idea. 
> > 
> > Marcus: could you please run your test twice with that patch? The first
> > time you run it as you did before, the second time please provide the
> > driver parameter "disable_hw_scan=1" together with the debug parameter.
> 
> Not wishing to muddy the waters, but I've found that the iwlwifi driver
> with a 3945 card is only reliable for scanning and associating for
> my laptop (x86_64) with disable_hw_scan=1 set, this is with
> 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
> 
> Previous to the recent heavy driver development, with 2.6.23.15-137.fc8
> the opposite was the case. This was driver version 1.2.23.
> 
> Currently with sw scanning *every* scan returns my own 2 APs, whereas
> using hw scanning I often receive "No scan results" and my 2 APs
> sometimes appear in the scan output and disappear frequently. It's
> equally unreliable when I can see my neighbours APs, the software scan
> is reliable when signals are strong enough to register at all.
> 
> One of the Fedora common bugs advised the used of sw scanning, this is
> still showing up on the common bugs list.

The specific issue that caused Linville and I to request that people use
disable_hw_scan=1 was to diagnose an issue with iwl3945 where the driver
would subsequently fail to find an AP that was previously associated
with, without an rmmod/modprobe cycle.

After resume from sleep or hibernate, and in some cases where the STA
got disconnected, even repeated 'iwlist wlan0 scan' would fail to find
the previously associated AP, despite showing up to 30 or so APs in the
area, and despite being just 30 FT away from one AP in the SSID.
Setting disable_hw_scan=1 "fixed" the issue, though we hadn't gotten too
far with debugging it yet.

Dan

Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Sat, 2008-04-19 at 15:51 +0200, Johannes Berg wrote:
> > > I'll leave it up to you (collective you, not necessarily a personal
> > > you), how to best deal with associating with APs which are not
> > > broadcasting their SSIDs. I agree with you (personal you this time) that
> > > roaming around the country broadcasting those SSIDs does not seem
> > > particularly desirable. So how should the ability to connect to non SSID
> > > broadcasting APs be implemented? 
> > 
> > I would probably list, in network-manager, "I found (a) hidden
> > network(s)" and ask the user for an SSID to scan for actively at that
> > particular time, rather than trying to scan for all previously known
> > SSIDs even if those networks weren't hidden, as windows laptops (at
> > least those with Intel hardware but I haven't seen many others) seem to
> > do.
> 
> Or it could remember the BSSID and when it encounters the BSSID again
> scan it actively to see if it still has the same (albeit hidden) SSID.

That's what NM does; NM will cache the BSSIDs of previously associated
APs and use that to determine which APs to connect to automatically.

wpa_supplicant, unfortunately, doesn't use this trick when associating
(since it doesn't really store state at all), and therefore in the
hidden AP case, NM passes "ap_scan=1 + scan_ssid=1" to probe-scan the AP
that we want to connect to.  But that's still only _one_ AP being
probe-scanned, not 4...

There's likely some room for improvement in wpa_supplicant here, since
there's added latency waiting for the supplicant to do scans when NM
already knows exactly which AP/BSSID to connect to already, but we can't
push the exact SSID into the supplicant's config, because that would
cause the supplicant to only ever assocate with that AP (I _think_ so at
least) and therefore not roam correctly.

Dan

> My N810 behaves that way too, incidentally, it seems to first scan
> broadcast but if you then don't select a network quickly it starts
> scanning all networks directedly that it has previously saved.
> 
> johannes

Re: RE: iwl3945 problem with 2.6.25-rc9

[Tomas Winkler]

On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  > Second the 3954 and 4965 my uCode may crash intentionally if you send
>  > probe requests on a passive channel.according EEPROM.
>
>  I really wonder what sort of error handling strategy that is, even if
>  it's done for regulatory compliance purposes I don't see a need to crash
>  the whole card. Especially considering that the userspace MLME in
>  wpa_supplicant will scan by itself (yes, it scans in userspace, whether
>  or not you may like that), of course it would be made comply with
>  regulatory settings but that makes it hard to develop.

It should not scan on not supported channel in any conditions. EEPROM
and reg.c has to be combined.

>
>  > I personally  wish to not make SW scanning possible at all for that reason.
>
>  That is not going to happen since you can always "scan" by sending probe
>  requests manually.

Probe request before association is  a must, no argue about it.

>  > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
>  > but currently wireless tools interface cannot utilize this.
>
>  Does anybody actually *want* that? I personally dislike the behaviour of
>  scanning for all previously known SSIDs actively when hidden SSIDs are
>  so uncommon, I see it as an information disclosure vulnerability.

Sure you want that. User space applications handles number of
preferred SSIDs, let's call them profiles. It's desired that you do
direct scan for those SSIDss for faster connection.
Currently it takes 20 minutes  for NM to connect to network I want in
crowded air. (I'm exaggerating now I don't have real number...  but
it's something like that)
It's not just for hidden ssids.

Tomas

Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> >
> >  > Second the 3954 and 4965 my uCode may crash intentionally if you send
> >  > probe requests on a passive channel.according EEPROM.
> >
> >  I really wonder what sort of error handling strategy that is, even if
> >  it's done for regulatory compliance purposes I don't see a need to crash
> >  the whole card. Especially considering that the userspace MLME in
> >  wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> >  or not you may like that), of course it would be made comply with
> >  regulatory settings but that makes it hard to develop.
> 
> It should not scan on not supported channel in any conditions. EEPROM
> and reg.c has to be combined.

The driver should _certainly_ be enforcing regulatory domains.  Even if
userspace requests a scan of a channel that is not available in the
regulatory domain, the driver needs to be rejecting the scan request in
situations where the firmware would reject it.

If the firmware triggers an assertion, that definitely indicates a bug
in the driver, where the driver is not properly gating options sent to
the firmware.  Only in the most exceptional circumstances should the
firmware actually crash.

> >
> >  > I personally  wish to not make SW scanning possible at all for that reason.
> >
> >  That is not going to happen since you can always "scan" by sending probe
> >  requests manually.
> 
> Probe request before association is  a must, no argue about it.
> 
> >  > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> >  > but currently wireless tools interface cannot utilize this.
> >
> >  Does anybody actually *want* that? I personally dislike the behaviour of
> >  scanning for all previously known SSIDs actively when hidden SSIDs are
> >  so uncommon, I see it as an information disclosure vulnerability.
> 
> Sure you want that. User space applications handles number of
> preferred SSIDs, let's call them profiles. It's desired that you do
> direct scan for those SSIDss for faster connection.
> Currently it takes 20 minutes  for NM to connect to network I want in
> crowded air. (I'm exaggerating now I don't have real number...  but
> it's something like that)

More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
need to be optimized somewhat.  Cards that advertise > 14 channels are
assumed to take a prohibitively long time to scan while connected
(madwifi was the largest offender here), and therefore NM will not
request scans for a/b/g devices while connected, but will collect and
use background scan results.

Dan

> It's not just for hidden ssids.
> 
> Tomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RE: iwl3945 problem with 2.6.25-rc9

[Tomas Winkler]

On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <dcbw@redhat.com> wrote:
> On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
>  > On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
>  > <johannes@sipsolutions.net> wrote:
>  > >
>  > >  > Second the 3954 and 4965 my uCode may crash intentionally if you send
>  > >  > probe requests on a passive channel.according EEPROM.
>  > >
>  > >  I really wonder what sort of error handling strategy that is, even if
>  > >  it's done for regulatory compliance purposes I don't see a need to crash
>  > >  the whole card. Especially considering that the userspace MLME in
>  > >  wpa_supplicant will scan by itself (yes, it scans in userspace, whether
>  > >  or not you may like that), of course it would be made comply with
>  > >  regulatory settings but that makes it hard to develop.
>  >
>  > It should not scan on not supported channel in any conditions. EEPROM
>  > and reg.c has to be combined.
>
>  The driver should _certainly_ be enforcing regulatory domains.  Even if
>  userspace requests a scan of a channel that is not available in the
>  regulatory domain, the driver needs to be rejecting the scan request in
>  situations where the firmware would reject it.

The problem is only in software scanning as the radio is tuned not
through the scanning code.
We need to fix this as passive channels are concern.

>  If the firmware triggers an assertion, that definitely indicates a bug
>  in the driver, where the driver is not properly gating options sent to
>  the firmware.  Only in the most exceptional circumstances should the
>  firmware actually crash.

Firmware might be crashed any time but wrong driver behavior. It's not
designed to be robust towards 'friendly driver' it supposed to be
defensive in way that it guarantees that it won't violated FCC.

>
>  > >
>  > >  > I personally  wish to not make SW scanning possible at all for that reason.
>  > >
>  > >  That is not going to happen since you can always "scan" by sending probe
>  > >  requests manually.
>  >
>  > Probe request before association is  a must, no argue about it.
>  >
>  > >  > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
>  > >  > but currently wireless tools interface cannot utilize this.
>  > >
>  > >  Does anybody actually *want* that? I personally dislike the behaviour of
>  > >  scanning for all previously known SSIDs actively when hidden SSIDs are
>  > >  so uncommon, I see it as an information disclosure vulnerability.
>  >
>  > Sure you want that. User space applications handles number of
>  > preferred SSIDs, let's call them profiles. It's desired that you do
>  > direct scan for those SSIDss for faster connection.
>  > Currently it takes 20 minutes  for NM to connect to network I want in
>  > crowded air. (I'm exaggerating now I don't have real number...  but
>  > it's something like that)
>
>  More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
>  need to be optimized somewhat.  Cards that advertise > 14 channels are
>  assumed to take a prohibitively long time to scan while connected
>  (madwifi was the largest offender here), and therefore NM will not
>  request scans for a/b/g devices while connected, but will collect and
>  use background scan results.
>
Actually in place with 70  and more APs I was never able to associate
with NM, only manual configuration works.
At my home place actually it works 100% but I have like 4 APs in surrounding.
I'm working with stock NM in latest F8.

Tomas

Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams]

On Mon, 2008-04-21 at 21:39 +0300, Tomas Winkler wrote:
> On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <dcbw@redhat.com> wrote:
> > On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> >  > On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> >  > <johannes@sipsolutions.net> wrote:
> >  > >
> >  > >  > Second the 3954 and 4965 my uCode may crash intentionally if you send
> >  > >  > probe requests on a passive channel.according EEPROM.
> >  > >
> >  > >  I really wonder what sort of error handling strategy that is, even if
> >  > >  it's done for regulatory compliance purposes I don't see a need to crash
> >  > >  the whole card. Especially considering that the userspace MLME in
> >  > >  wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> >  > >  or not you may like that), of course it would be made comply with
> >  > >  regulatory settings but that makes it hard to develop.
> >  >
> >  > It should not scan on not supported channel in any conditions. EEPROM
> >  > and reg.c has to be combined.
> >
> >  The driver should _certainly_ be enforcing regulatory domains.  Even if
> >  userspace requests a scan of a channel that is not available in the
> >  regulatory domain, the driver needs to be rejecting the scan request in
> >  situations where the firmware would reject it.
> 
> The problem is only in software scanning as the radio is tuned not
> through the scanning code.
> We need to fix this as passive channels are concern.
> 
> >  If the firmware triggers an assertion, that definitely indicates a bug
> >  in the driver, where the driver is not properly gating options sent to
> >  the firmware.  Only in the most exceptional circumstances should the
> >  firmware actually crash.
> 
> Firmware might be crashed any time but wrong driver behavior. It's not
> designed to be robust towards 'friendly driver' it supposed to be
> defensive in way that it guarantees that it won't violated FCC.
> 
> >
> >  > >
> >  > >  > I personally  wish to not make SW scanning possible at all for that reason.
> >  > >
> >  > >  That is not going to happen since you can always "scan" by sending probe
> >  > >  requests manually.
> >  >
> >  > Probe request before association is  a must, no argue about it.
> >  >
> >  > >  > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> >  > >  > but currently wireless tools interface cannot utilize this.
> >  > >
> >  > >  Does anybody actually *want* that? I personally dislike the behaviour of
> >  > >  scanning for all previously known SSIDs actively when hidden SSIDs are
> >  > >  so uncommon, I see it as an information disclosure vulnerability.
> >  >
> >  > Sure you want that. User space applications handles number of
> >  > preferred SSIDs, let's call them profiles. It's desired that you do
> >  > direct scan for those SSIDss for faster connection.
> >  > Currently it takes 20 minutes  for NM to connect to network I want in
> >  > crowded air. (I'm exaggerating now I don't have real number...  but
> >  > it's something like that)
> >
> >  More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
> >  need to be optimized somewhat.  Cards that advertise > 14 channels are
> >  assumed to take a prohibitively long time to scan while connected
> >  (madwifi was the largest offender here), and therefore NM will not
> >  request scans for a/b/g devices while connected, but will collect and
> >  use background scan results.
> >
> Actually in place with 70  and more APs I was never able to associate
> with NM, only manual configuration works.
> At my home place actually it works 100% but I have like 4 APs in surrounding.
> I'm working with stock NM in latest F8.

Probably a supplicant issue here, since wpa_supplicant doesn't cache
scan results over time (like NM does) and therefore when NM asks the
supplicant to associate, the supplicant has to scan _again_ to find the
network to associate with.  You could probably reproduce by creating a
supplicant config file and trying to associate with wpa_supplicant and
scan_ssid=1 + ap_scan=1 like NM is doing.

There's some consensus about fixing this upstream in wpa_supplicant, but
there's nobody working on it quite yet.

dan

Re: RE: iwl3945 problem with 2.6.25-rc9

[Tomas Winkler]

On Mon, Apr 21, 2008 at 10:20 PM, Dan Williams <dcbw@redhat.com> wrote:
>
> On Mon, 2008-04-21 at 21:39 +0300, Tomas Winkler wrote:
>  > On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <dcbw@redhat.com> wrote:
>  > > On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
>  > >  > On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
>  > >  > <johannes@sipsolutions.net> wrote:
>  > >  > >
>  > >  > >  > Second the 3954 and 4965 my uCode may crash intentionally if you send
>  > >  > >  > probe requests on a passive channel.according EEPROM.
>  > >  > >
>  > >  > >  I really wonder what sort of error handling strategy that is, even if
>  > >  > >  it's done for regulatory compliance purposes I don't see a need to crash
>  > >  > >  the whole card. Especially considering that the userspace MLME in
>  > >  > >  wpa_supplicant will scan by itself (yes, it scans in userspace, whether
>  > >  > >  or not you may like that), of course it would be made comply with
>  > >  > >  regulatory settings but that makes it hard to develop.
>  > >  >
>  > >  > It should not scan on not supported channel in any conditions. EEPROM
>  > >  > and reg.c has to be combined.
>  > >
>  > >  The driver should _certainly_ be enforcing regulatory domains.  Even if
>  > >  userspace requests a scan of a channel that is not available in the
>  > >  regulatory domain, the driver needs to be rejecting the scan request in
>  > >  situations where the firmware would reject it.
>  >
>  > The problem is only in software scanning as the radio is tuned not
>  > through the scanning code.
>  > We need to fix this as passive channels are concern.
>  >
>  > >  If the firmware triggers an assertion, that definitely indicates a bug
>  > >  in the driver, where the driver is not properly gating options sent to
>  > >  the firmware.  Only in the most exceptional circumstances should the
>  > >  firmware actually crash.
>  >
>  > Firmware might be crashed any time but wrong driver behavior. It's not
>  > designed to be robust towards 'friendly driver' it supposed to be
>  > defensive in way that it guarantees that it won't violated FCC.
>  >
>  > >
>  > >  > >
>  > >  > >  > I personally  wish to not make SW scanning possible at all for that reason.
>  > >  > >
>  > >  > >  That is not going to happen since you can always "scan" by sending probe
>  > >  > >  requests manually.
>  > >  >
>  > >  > Probe request before association is  a must, no argue about it.
>  > >  >
>  > >  > >  > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
>  > >  > >  > but currently wireless tools interface cannot utilize this.
>  > >  > >
>  > >  > >  Does anybody actually *want* that? I personally dislike the behaviour of
>  > >  > >  scanning for all previously known SSIDs actively when hidden SSIDs are
>  > >  > >  so uncommon, I see it as an information disclosure vulnerability.
>  > >  >
>  > >  > Sure you want that. User space applications handles number of
>  > >  > preferred SSIDs, let's call them profiles. It's desired that you do
>  > >  > direct scan for those SSIDss for faster connection.
>  > >  > Currently it takes 20 minutes  for NM to connect to network I want in
>  > >  > crowded air. (I'm exaggerating now I don't have real number...  but
>  > >  > it's something like that)
>  > >
>  > >  More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
>  > >  need to be optimized somewhat.  Cards that advertise > 14 channels are
>  > >  assumed to take a prohibitively long time to scan while connected
>  > >  (madwifi was the largest offender here), and therefore NM will not
>  > >  request scans for a/b/g devices while connected, but will collect and
>  > >  use background scan results.
>  > >
>  > Actually in place with 70  and more APs I was never able to associate
>  > with NM, only manual configuration works.
>  > At my home place actually it works 100% but I have like 4 APs in surrounding.
>  > I'm working with stock NM in latest F8.
>
>  Probably a supplicant issue here, since wpa_supplicant doesn't cache
>  scan results over time (like NM does) and therefore when NM asks the
>  supplicant to associate, the supplicant has to scan _again_ to find the
>  network to associate with.  You could probably reproduce by creating a
>  supplicant config file and trying to associate with wpa_supplicant and
>  scan_ssid=1 + ap_scan=1 like NM is doing.
>
>  There's some consensus about fixing this upstream in wpa_supplicant, but
>  there's nobody working on it quite yet.
>
Thanks for info, will try
>  dan
>
>
>

RE: iwl3945 problem with 2.6.25-rc9

[Chatre, Reinette]

On Friday, April 18, 2008 7:33 PM, Marcus Furlong  wrote:


> Both dmesg logs here:
> 
> https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
> https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
> -disable_hw_scan 

This is very strange. Did anything change in your setup since you sent
the logs that created the debug file named
"2.6.25-dmesg-wirelesstools-only"? In the above log
2.6.25-dmesg-with-patch hardware scanning is indeed being used ... while
it was not in the previous test runs. Note the debug message
"iwl3945_mac_hw_scan enter" and "iwl3945_mac_hw_scan leave". This
message only appears in this log (2.6.25-dmesg-with-patch) and none of
the others.
I find it very hard to believe that this patch caused hw scanning to
work all of a sudden. 

Reinette

RE: iwl3945 problem with 2.6.25-rc9

[Marcus Furlong]

On Wednesday 23 April 2008 00:02 in
<D936D925018D154694D8A362EEB0892004415152@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:

> On Friday, April 18, 2008 7:33 PM, Marcus Furlong  wrote:
> 
> 
>> Both dmesg logs here:
>> 
>> https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
>> https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
>> -disable_hw_scan
> 
> This is very strange. Did anything change in your setup since you sent
> the logs that created the debug file named
> "2.6.25-dmesg-wirelesstools-only"? In the above log
> 2.6.25-dmesg-with-patch hardware scanning is indeed being used ... while
> it was not in the previous test runs. Note the debug message
> "iwl3945_mac_hw_scan enter" and "iwl3945_mac_hw_scan leave". This
> message only appears in this log (2.6.25-dmesg-with-patch) and none of
> the others.
> I find it very hard to believe that this patch caused hw scanning to
> work all of a sudden.

Since the first one, I disabled autoloading of the module during boot and
removed the wireless device from the udev startup scripts and added it to a
udev blacklist,  so that I could load it manually without unloading first.
So maybe there was something in the startup scripts causing this (i.e. the
option with disable_hw_scan somewhere). I just deleted all related files
to "start cleanly" so I didn't keep a backup that I can check. :( Looks
like the dmesg output doesn't show which options the module was loaded
with, maybe this would be handy in future?

Marcus.