iwl3945 doesn't work

iwl3945 doesn't work

[Jens Axboe]

Hi,

Seeing that iwl3945 is now merged, I decided to switch my x60 to use
that instead of ipw3945. That would leave me with zero kernel
dependencies.

Unfortunately it doesn't work. Loading the module reveals the device:

iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
Linux, 1.1.17ks
iwl3945: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:03:00.0 to 64
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
phy0: Selected rate control algorithm 'iwl-3945-rs'

# iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"  
          Mode:Managed  Channel:0  Access Point: Not-Associated   
          Tx-Power=0 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
          Encryption key:XXXX-XXXX-XX
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

and iwconfig sees it, essid/enc settings are fine, but I don't get a
link.

-- 
Jens Axboe

Re: iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Jens Axboe wrote:
> Hi,
> 
> Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> that instead of ipw3945. That would leave me with zero kernel
> dependencies.
> 
> Unfortunately it doesn't work. Loading the module reveals the device:
> 
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
> 
> # iwconfig wlan0
> wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"  
>           Mode:Managed  Channel:0  Access Point: Not-Associated   
>           Tx-Power=0 dBm   
>           Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
>           Encryption key:XXXX-XXXX-XX
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.

I should mention that ipw3945 has always worked fine for me. And please
don't drop me from the CC list, I'm not subscribed to either of the
lists.

-- 
Jens Axboe

Re: iwl3945 doesn't work

[John W. Linville]

On Wed, Oct 17, 2007 at 03:54:53PM +0200, Jens Axboe wrote:

> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
> 
> # iwconfig wlan0
> wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"  
>           Mode:Managed  Channel:0  Access Point: Not-Associated   
>           Tx-Power=0 dBm   
>           Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
>           Encryption key:XXXX-XXXX-XX
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.

Seems like "so far, so good" except for the "don't get a link"
part...what is the output of iwlist wlan0 scan?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: iwl3945 doesn't work

[Ismail Dönmez]

Wednesday 17 October 2007 Tarihinde 16:54:53 yazm=C4=B1=C5=9Ft=C4=B1:
> Hi,
>
> Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> that instead of ipw3945. That would leave me with zero kernel
> dependencies.
>
> Unfortunately it doesn't work. Loading the module reveals the device:
>
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver f=
or
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
>
> # iwconfig wlan0
> wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
>           Mode:Managed  Channel:0  Access Point: Not-Associated
>           Tx-Power=3D0 dBm
>           Retry min limit:7   RTS thr:off   Fragment thr=3D2346 B
>           Encryption key:XXXX-XXXX-XX
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.

Same issue here, try iwlist wlan0 scan first and then it should work.

Regards,
ismail

--=20
=46aith is believing what you know isn't so -- Mark Twain
-
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: iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > Hi,
> >
> > Seeing that iwl3945 is now merged, I decided to switch my x60 to us=
e
> > that instead of ipw3945. That would leave me with zero kernel
> > dependencies.
> >
> > Unfortunately it doesn't work. Loading the module reveals the devic=
e:
> >
> > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver=
 for
> > Linux, 1.1.17ks
> > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 2=
1
> > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > phy0: Selected rate control algorithm 'iwl-3945-rs'
> >
> > # iwconfig wlan0
> > wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
> >           Mode:Managed  Channel:0  Access Point: Not-Associated
> >           Tx-Power=3D0 dBm
> >           Retry min limit:7   RTS thr:off   Fragment thr=3D2346 B
> >           Encryption key:XXXX-XXXX-XX
> >           Link Quality:0  Signal level:0  Noise level:0
> >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
> >           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> >
> > and iwconfig sees it, essid/enc settings are fine, but I don't get =
a
> > link.
>=20
> Same issue here, try iwlist wlan0 scan first and then it should work.

Huh indeed, now it links fine! Thanks for the hint. Would be nice to
have fixed, though :-)

--=20
Jens Axboe

-
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: iwl3945 doesn't work

[Ismail Dönmez]

Wednesday 17 October 2007 Tarihinde 17:11:11 yazm=C4=B1=C5=9Ft=C4=B1:
> Huh indeed, now it links fine! Thanks for the hint. Would be nice to
> have fixed, though :-)

Yeah indeed I sent a mail about this a couple of days ago, waiting for =
Intel=20
guys to respond :-)

Regards,
ismail

--=20
=46aith is believing what you know isn't so -- Mark Twain
-
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: iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> Wednesday 17 October 2007 Tarihinde 17:11:11 yazm????t??:
> > Huh indeed, now it links fine! Thanks for the hint. Would be nice t=
o
> > have fixed, though :-)
>=20
> Yeah indeed I sent a mail about this a couple of days ago, waiting fo=
r
> Intel guys to respond :-)

At least this makes my notebook usable until they get it fixed, so
thanks a lot for the hint!

--=20
Jens Axboe

-
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: iwl3945 doesn't work

[Dan Williams]

On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> On Wed, Oct 17 2007, Ismail D=C3=B6nmez wrote:
> > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > Hi,
> > >
> > > Seeing that iwl3945 is now merged, I decided to switch my x60 to =
use
> > > that instead of ipw3945. That would leave me with zero kernel
> > > dependencies.
> > >
> > > Unfortunately it doesn't work. Loading the module reveals the dev=
ice:
> > >
> > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driv=
er for
> > > Linux, 1.1.17ks
> > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ=
 21
> > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > >
> > > # iwconfig wlan0
> > > wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
> > >           Mode:Managed  Channel:0  Access Point: Not-Associated
> > >           Tx-Power=3D0 dBm
> > >           Retry min limit:7   RTS thr:off   Fragment thr=3D2346 B
> > >           Encryption key:XXXX-XXXX-XX
> > >           Link Quality:0  Signal level:0  Noise level:0
> > >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:=
0
> > >           Tx excessive retries:0  Invalid misc:0   Missed beacon:=
0
> > >
> > > and iwconfig sees it, essid/enc settings are fine, but I don't ge=
t a
> > > link.
> >=20
> > Same issue here, try iwlist wlan0 scan first and then it should wor=
k.
>=20
> Huh indeed, now it links fine! Thanks for the hint. Would be nice to
> have fixed, though :-)

Odd, doesn't the driver need to do a scan _anyway_ to find the right
BSSID to associate with if the cached scan results are more than a few
seconds old?  Can you run '/sbin/iwevent' before trying a fresh
association, try to associate, ensure that it has failed, and report th=
e
output?

If you don't get something like:

10:17:05.117937   eth1     Scan request completed

shown there, then there's likely a bug in the driver because it's eithe=
r
(a) not scanning before trying to associate, or (b) not sending out sca=
n
completion events after it's done a scan.

Dan


-
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: iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Dan Williams wrote:
> On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> > On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> > > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > > Hi,
> > > >
> > > > Seeing that iwl3945 is now merged, I decided to switch my x60 t=
o use
> > > > that instead of ipw3945. That would leave me with zero kernel
> > > > dependencies.
> > > >
> > > > Unfortunately it doesn't work. Loading the module reveals the d=
evice:
> > > >
> > > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection dr=
iver for
> > > > Linux, 1.1.17ks
> > > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> I=
RQ 21
> > > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > > >
> > > > # iwconfig wlan0
> > > > wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
> > > >           Mode:Managed  Channel:0  Access Point: Not-Associated
> > > >           Tx-Power=3D0 dBm
> > > >           Retry min limit:7   RTS thr:off   Fragment thr=3D2346=
 B
> > > >           Encryption key:XXXX-XXXX-XX
> > > >           Link Quality:0  Signal level:0  Noise level:0
> > > >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid fra=
g:0
> > > >           Tx excessive retries:0  Invalid misc:0   Missed beaco=
n:0
> > > >
> > > > and iwconfig sees it, essid/enc settings are fine, but I don't =
get a
> > > > link.
> > >=20
> > > Same issue here, try iwlist wlan0 scan first and then it should w=
ork.
> >=20
> > Huh indeed, now it links fine! Thanks for the hint. Would be nice t=
o
> > have fixed, though :-)
>=20
> Odd, doesn't the driver need to do a scan _anyway_ to find the right
> BSSID to associate with if the cached scan results are more than a fe=
w
> seconds old?  Can you run '/sbin/iwevent' before trying a fresh
> association, try to associate, ensure that it has failed, and report =
the
> output?
>=20
> If you don't get something like:
>=20
> 10:17:05.117937   eth1     Scan request completed
>=20
> shown there, then there's likely a bug in the driver because it's eit=
her
> (a) not scanning before trying to associate, or (b) not sending out s=
can
> completion events after it's done a scan.

Indeed, there is now Scan request completed before I run the iwlist
scan. iwevent output:

Waiting for Wireless Events from interfaces...
16:20:27.453588   wlan0    Set Mode:Managed
16:20:27.462104   wlan0    Set Encryption key:off
16:20:27.463940   wlan0    Set Encryption key:****-****-**   Security m=
ode:open
16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"

waiting, nothing else happens. Then run iwlist scan from another
terminal.

16:20:53.892549   wlan0    Scan request completed
16:20:54.025085   wlan0    Custom driver
event:ASSOCINFO(ReqIEs=3D000e6b6a656c6c626572676178626f65010402040b16
RespIEs=3D010482848b96dd0c00037f0201015b0002a44000)
16:20:54.025123   wlan0    New Access Point/Cell address:00:13:46:97:33=
:E2

bingo, it associates and it now works.

--=20
Jens Axboe

-
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: iwl3945 doesn't work

[Dan Williams]

On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
> On Wed, Oct 17 2007, Dan Williams wrote:
> > On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> > > On Wed, Oct 17 2007, Ismail D=C3=B6nmez wrote:
> > > > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > > > Hi,
> > > > >
> > > > > Seeing that iwl3945 is now merged, I decided to switch my x60=
 to use
> > > > > that instead of ipw3945. That would leave me with zero kernel
> > > > > dependencies.
> > > > >
> > > > > Unfortunately it doesn't work. Loading the module reveals the=
 device:
> > > > >
> > > > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection =
driver for
> > > > > Linux, 1.1.17ks
> > > > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) ->=
 IRQ 21
> > > > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connecti=
on
> > > > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > > > >
> > > > > # iwconfig wlan0
> > > > > wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
> > > > >           Mode:Managed  Channel:0  Access Point: Not-Associat=
ed
> > > > >           Tx-Power=3D0 dBm
> > > > >           Retry min limit:7   RTS thr:off   Fragment thr=3D23=
46 B
> > > > >           Encryption key:XXXX-XXXX-XX
> > > > >           Link Quality:0  Signal level:0  Noise level:0
> > > > >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid f=
rag:0
> > > > >           Tx excessive retries:0  Invalid misc:0   Missed bea=
con:0
> > > > >
> > > > > and iwconfig sees it, essid/enc settings are fine, but I don'=
t get a
> > > > > link.
> > > >=20
> > > > Same issue here, try iwlist wlan0 scan first and then it should=
 work.
> > >=20
> > > Huh indeed, now it links fine! Thanks for the hint. Would be nice=
 to
> > > have fixed, though :-)
> >=20
> > Odd, doesn't the driver need to do a scan _anyway_ to find the righ=
t
> > BSSID to associate with if the cached scan results are more than a =
few
> > seconds old?  Can you run '/sbin/iwevent' before trying a fresh
> > association, try to associate, ensure that it has failed, and repor=
t the
> > output?
> >=20
> > If you don't get something like:
> >=20
> > 10:17:05.117937   eth1     Scan request completed
> >=20
> > shown there, then there's likely a bug in the driver because it's e=
ither
> > (a) not scanning before trying to associate, or (b) not sending out=
 scan
> > completion events after it's done a scan.
>=20
> Indeed, there is now Scan request completed before I run the iwlist
> scan. iwevent output:

Hmm, the output below doesn't show the scan request completed, right?

> Waiting for Wireless Events from interfaces...
> 16:20:27.453588   wlan0    Set Mode:Managed
> 16:20:27.462104   wlan0    Set Encryption key:off
> 16:20:27.463940   wlan0    Set Encryption key:****-****-**   Security=
 mode:open
> 16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"
>=20
> waiting, nothing else happens. Then run iwlist scan from another
> terminal.
>=20
> 16:20:53.892549   wlan0    Scan request completed

So you only get this when you manually scan right after setting the ssi=
d
and key?

Dan

> 16:20:54.025085   wlan0    Custom driver
> event:ASSOCINFO(ReqIEs=3D000e6b6a656c6c626572676178626f65010402040b16
> RespIEs=3D010482848b96dd0c00037f0201015b0002a44000)
> 16:20:54.025123   wlan0    New Access Point/Cell address:00:13:46:97:=
33:E2
>=20
> bingo, it associates and it now works.
>=20

-
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: iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Dan Williams wrote:
> On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
> > On Wed, Oct 17 2007, Dan Williams wrote:
> > > On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> > > > On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> > > > > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > > > > Hi,
> > > > > >
> > > > > > Seeing that iwl3945 is now merged, I decided to switch my x=
60 to use
> > > > > > that instead of ipw3945. That would leave me with zero kern=
el
> > > > > > dependencies.
> > > > > >
> > > > > > Unfortunately it doesn't work. Loading the module reveals t=
he device:
> > > > > >
> > > > > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connectio=
n driver for
> > > > > > Linux, 1.1.17ks
> > > > > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > > > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) =
-> IRQ 21
> > > > > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > > > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connec=
tion
> > > > > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > > > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > > > > >
> > > > > > # iwconfig wlan0
> > > > > > wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
> > > > > >           Mode:Managed  Channel:0  Access Point: Not-Associ=
ated
> > > > > >           Tx-Power=3D0 dBm
> > > > > >           Retry min limit:7   RTS thr:off   Fragment thr=3D=
2346 B
> > > > > >           Encryption key:XXXX-XXXX-XX
> > > > > >           Link Quality:0  Signal level:0  Noise level:0
> > > > > >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid=
 frag:0
> > > > > >           Tx excessive retries:0  Invalid misc:0   Missed b=
eacon:0
> > > > > >
> > > > > > and iwconfig sees it, essid/enc settings are fine, but I do=
n't get a
> > > > > > link.
> > > > >=20
> > > > > Same issue here, try iwlist wlan0 scan first and then it shou=
ld work.
> > > >=20
> > > > Huh indeed, now it links fine! Thanks for the hint. Would be ni=
ce to
> > > > have fixed, though :-)
> > >=20
> > > Odd, doesn't the driver need to do a scan _anyway_ to find the ri=
ght
> > > BSSID to associate with if the cached scan results are more than =
a few
> > > seconds old?  Can you run '/sbin/iwevent' before trying a fresh
> > > association, try to associate, ensure that it has failed, and rep=
ort the
> > > output?
> > >=20
> > > If you don't get something like:
> > >=20
> > > 10:17:05.117937   eth1     Scan request completed
> > >=20
> > > shown there, then there's likely a bug in the driver because it's=
 either
> > > (a) not scanning before trying to associate, or (b) not sending o=
ut scan
> > > completion events after it's done a scan.
> >=20
> > Indeed, there is now Scan request completed before I run the iwlist
> > scan. iwevent output:
>=20
> Hmm, the output below doesn't show the scan request completed, right?
>=20
> > Waiting for Wireless Events from interfaces...
> > 16:20:27.453588   wlan0    Set Mode:Managed
> > 16:20:27.462104   wlan0    Set Encryption key:off
> > 16:20:27.463940   wlan0    Set Encryption key:****-****-**   Securi=
ty mode:open
> > 16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"
> >=20
> > waiting, nothing else happens. Then run iwlist scan from another
> > terminal.
> >=20
> > 16:20:53.892549   wlan0    Scan request completed
>=20
> So you only get this when you manually scan right after setting the s=
sid
> and key?

If you look at the time stamp, I ran the iwlist scan about 26 seconds
after loading the module. When the module is loaded, the networking
script sets the essid and encryption key.

So yes, I only get that 'Scan request completed' line after running
iwlist scan manually.

--=20
Jens Axboe

-
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: [ipw3945-devel] iwl3945 doesn't work

[Stephen Clark]

Jens Axboe wrote:

>On Wed, Oct 17 2007, Dan Williams wrote:
> =20
>
>>On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>   =20
>>
>>>On Wed, Oct 17 2007, Dan Williams wrote:
>>>     =20
>>>
>>>>On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>       =20
>>>>
>>>>>On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>         =20
>>>>>
>>>>>>Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>           =20
>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>Seeing that iwl3945 is now merged, I decided to switch my x60 to=
 use
>>>>>>>that instead of ipw3945. That would leave me with zero kernel
>>>>>>>dependencies.
>>>>>>>
>>>>>>>Unfortunately it doesn't work. Loading the module reveals the de=
vice:
>>>>>>>
>>>>>>>iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection dri=
ver for
>>>>>>>Linux, 1.1.17ks
>>>>>>>iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IR=
Q 21
>>>>>>>PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
>>>>>>>iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>
>>>>>>># iwconfig wlan0
>>>>>>>wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
>>>>>>>          Mode:Managed  Channel:0  Access Point: Not-Associated
>>>>>>>          Tx-Power=3D0 dBm
>>>>>>>          Retry min limit:7   RTS thr:off   Fragment thr=3D2346 =
B
>>>>>>>          Encryption key:XXXX-XXXX-XX
>>>>>>>          Link Quality:0  Signal level:0  Noise level:0
>>>>>>>          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag=
:0
>>>>>>>          Tx excessive retries:0  Invalid misc:0   Missed beacon=
:0
>>>>>>>
>>>>>>>and iwconfig sees it, essid/enc settings are fine, but I don't g=
et a
>>>>>>>link.
>>>>>>>             =20
>>>>>>>
>>>>>>Same issue here, try iwlist wlan0 scan first and then it should w=
ork.
>>>>>>           =20
>>>>>>
>>>>>Huh indeed, now it links fine! Thanks for the hint. Would be nice =
to
>>>>>have fixed, though :-)
>>>>>         =20
>>>>>
>>>>Odd, doesn't the driver need to do a scan _anyway_ to find the righ=
t
>>>>BSSID to associate with if the cached scan results are more than a =
few
>>>>seconds old?  Can you run '/sbin/iwevent' before trying a fresh
>>>>association, try to associate, ensure that it has failed, and repor=
t the
>>>>output?
>>>>
>>>>If you don't get something like:
>>>>
>>>>10:17:05.117937   eth1     Scan request completed
>>>>
>>>>shown there, then there's likely a bug in the driver because it's e=
ither
>>>>(a) not scanning before trying to associate, or (b) not sending out=
 scan
>>>>completion events after it's done a scan.
>>>>       =20
>>>>
>>>Indeed, there is now Scan request completed before I run the iwlist
>>>scan. iwevent output:
>>>     =20
>>>
>>Hmm, the output below doesn't show the scan request completed, right?
>>
>>   =20
>>
>>>Waiting for Wireless Events from interfaces...
>>>16:20:27.453588   wlan0    Set Mode:Managed
>>>16:20:27.462104   wlan0    Set Encryption key:off
>>>16:20:27.463940   wlan0    Set Encryption key:****-****-**   Securit=
y mode:open
>>>16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"
>>>
>>>waiting, nothing else happens. Then run iwlist scan from another
>>>terminal.
>>>
>>>16:20:53.892549   wlan0    Scan request completed
>>>     =20
>>>
>>So you only get this when you manually scan right after setting the s=
sid
>>and key?
>>   =20
>>
>
>If you look at the time stamp, I ran the iwlist scan about 26 seconds
>after loading the module. When the module is loaded, the networking
>script sets the essid and encryption key.
>
>So yes, I only get that 'Scan request completed' line after running
>iwlist scan manually.
>
> =20
>
Don't know whether this is related, but I was having all kinds of=20
trouble getting associated,
iwlist eth1 scan would report no scan results, I then switched to=20
loading the kernel module with
the option that tells  iwl3945 to do software scanning and it works=20
everytime now.

Steve

--=20

"They that give up essential liberty to obtain temporary safety,=20
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty=20
decreases."  (Thomas Jefferson)



-
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: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Stephen Clark wrote:
> Jens Axboe wrote:
>
>> On Wed, Oct 17 2007, Dan Williams wrote:
>> =20
>>> On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>>   =20
>>>> On Wed, Oct 17 2007, Dan Williams wrote:
>>>>     =20
>>>>> On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>>       =20
>>>>>> On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>>         =20
>>>>>>> Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>>           =20
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Seeing that iwl3945 is now merged, I decided to switch my x60 =
to use
>>>>>>>> that instead of ipw3945. That would leave me with zero kernel
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>> Unfortunately it doesn't work. Loading the module reveals the=20
>>>>>>>> device:
>>>>>>>>
>>>>>>>> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection d=
river=20
>>>>>>>> for
>>>>>>>> Linux, 1.1.17ks
>>>>>>>> iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> =
IRQ 21
>>>>>>>> PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connectio=
n
>>>>>>>> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>> phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>>
>>>>>>>> # iwconfig wlan0
>>>>>>>> wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
>>>>>>>>          Mode:Managed  Channel:0  Access Point: Not-Associated
>>>>>>>>          Tx-Power=3D0 dBm
>>>>>>>>          Retry min limit:7   RTS thr:off   Fragment thr=3D2346=
 B
>>>>>>>>          Encryption key:XXXX-XXXX-XX
>>>>>>>>          Link Quality:0  Signal level:0  Noise level:0
>>>>>>>>          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid fra=
g:0
>>>>>>>>          Tx excessive retries:0  Invalid misc:0   Missed beaco=
n:0
>>>>>>>>
>>>>>>>> and iwconfig sees it, essid/enc settings are fine, but I don't=
 get a
>>>>>>>> link.
>>>>>>>>             =20
>>>>>>> Same issue here, try iwlist wlan0 scan first and then it should=
 work.
>>>>>>>           =20
>>>>>> Huh indeed, now it links fine! Thanks for the hint. Would be nic=
e to
>>>>>> have fixed, though :-)
>>>>>>         =20
>>>>> Odd, doesn't the driver need to do a scan _anyway_ to find the ri=
ght
>>>>> BSSID to associate with if the cached scan results are more than =
a few
>>>>> seconds old?  Can you run '/sbin/iwevent' before trying a fresh
>>>>> association, try to associate, ensure that it has failed, and rep=
ort=20
>>>>> the
>>>>> output?
>>>>>
>>>>> If you don't get something like:
>>>>>
>>>>> 10:17:05.117937   eth1     Scan request completed
>>>>>
>>>>> shown there, then there's likely a bug in the driver because it's=
=20
>>>>> either
>>>>> (a) not scanning before trying to associate, or (b) not sending o=
ut=20
>>>>> scan
>>>>> completion events after it's done a scan.
>>>>>       =20
>>>> Indeed, there is now Scan request completed before I run the iwlis=
t
>>>> scan. iwevent output:
>>>>     =20
>>> Hmm, the output below doesn't show the scan request completed, righ=
t?
>>>
>>>   =20
>>>> Waiting for Wireless Events from interfaces...
>>>> 16:20:27.453588   wlan0    Set Mode:Managed
>>>> 16:20:27.462104   wlan0    Set Encryption key:off
>>>> 16:20:27.463940   wlan0    Set Encryption key:****-****-**   Secur=
ity=20
>>>> mode:open
>>>> 16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"
>>>>
>>>> waiting, nothing else happens. Then run iwlist scan from another
>>>> terminal.
>>>>
>>>> 16:20:53.892549   wlan0    Scan request completed
>>>>     =20
>>> So you only get this when you manually scan right after setting the=
 ssid
>>> and key?
>>>   =20
>>
>> If you look at the time stamp, I ran the iwlist scan about 26 second=
s
>> after loading the module. When the module is loaded, the networking
>> script sets the essid and encryption key.
>>
>> So yes, I only get that 'Scan request completed' line after running
>> iwlist scan manually.
>>
>> =20
> Don't know whether this is related, but I was having all kinds of tro=
uble=20
> getting associated,
> iwlist eth1 scan would report no scan results, I then switched to loa=
ding=20
> the kernel module with
> the option that tells  iwl3945 to do software scanning and it works=20
> everytime now.

Which option is that?

--=20
Jens Axboe

-
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: [ipw3945-devel] iwl3945 doesn't work

[Stephen Clark]

Jens Axboe wrote:

>On Wed, Oct 17 2007, Stephen Clark wrote:
> =20
>
>>Jens Axboe wrote:
>>
>>   =20
>>
>>>On Wed, Oct 17 2007, Dan Williams wrote:
>>>=20
>>>     =20
>>>
>>>>On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>>>  =20
>>>>       =20
>>>>
>>>>>On Wed, Oct 17 2007, Dan Williams wrote:
>>>>>    =20
>>>>>         =20
>>>>>
>>>>>>On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>>>      =20
>>>>>>           =20
>>>>>>
>>>>>>>On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>>>        =20
>>>>>>>             =20
>>>>>>>
>>>>>>>>Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>>>          =20
>>>>>>>>               =20
>>>>>>>>
>>>>>>>>>Hi,
>>>>>>>>>
>>>>>>>>>Seeing that iwl3945 is now merged, I decided to switch my x60 =
to use
>>>>>>>>>that instead of ipw3945. That would leave me with zero kernel
>>>>>>>>>dependencies.
>>>>>>>>>
>>>>>>>>>Unfortunately it doesn't work. Loading the module reveals the=20
>>>>>>>>>device:
>>>>>>>>>
>>>>>>>>>iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection d=
river=20
>>>>>>>>>for
>>>>>>>>>Linux, 1.1.17ks
>>>>>>>>>iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>>>ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> =
IRQ 21
>>>>>>>>>PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>>>iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connectio=
n
>>>>>>>>>iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>>>phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>>>
>>>>>>>>># iwconfig wlan0
>>>>>>>>>wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
>>>>>>>>>         Mode:Managed  Channel:0  Access Point: Not-Associated
>>>>>>>>>         Tx-Power=3D0 dBm
>>>>>>>>>         Retry min limit:7   RTS thr:off   Fragment thr=3D2346=
 B
>>>>>>>>>         Encryption key:XXXX-XXXX-XX
>>>>>>>>>         Link Quality:0  Signal level:0  Noise level:0
>>>>>>>>>         Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid fra=
g:0
>>>>>>>>>         Tx excessive retries:0  Invalid misc:0   Missed beaco=
n:0
>>>>>>>>>
>>>>>>>>>and iwconfig sees it, essid/enc settings are fine, but I don't=
 get a
>>>>>>>>>link.
>>>>>>>>>            =20
>>>>>>>>>                 =20
>>>>>>>>>
>>>>>>>>Same issue here, try iwlist wlan0 scan first and then it should=
 work.
>>>>>>>>          =20
>>>>>>>>               =20
>>>>>>>>
>>>>>>>Huh indeed, now it links fine! Thanks for the hint. Would be nic=
e to
>>>>>>>have fixed, though :-)
>>>>>>>        =20
>>>>>>>             =20
>>>>>>>
>>>>>>Odd, doesn't the driver need to do a scan _anyway_ to find the ri=
ght
>>>>>>BSSID to associate with if the cached scan results are more than =
a few
>>>>>>seconds old?  Can you run '/sbin/iwevent' before trying a fresh
>>>>>>association, try to associate, ensure that it has failed, and rep=
ort=20
>>>>>>the
>>>>>>output?
>>>>>>
>>>>>>If you don't get something like:
>>>>>>
>>>>>>10:17:05.117937   eth1     Scan request completed
>>>>>>
>>>>>>shown there, then there's likely a bug in the driver because it's=
=20
>>>>>>either
>>>>>>(a) not scanning before trying to associate, or (b) not sending o=
ut=20
>>>>>>scan
>>>>>>completion events after it's done a scan.
>>>>>>      =20
>>>>>>           =20
>>>>>>
>>>>>Indeed, there is now Scan request completed before I run the iwlis=
t
>>>>>scan. iwevent output:
>>>>>    =20
>>>>>         =20
>>>>>
>>>>Hmm, the output below doesn't show the scan request completed, righ=
t?
>>>>
>>>>  =20
>>>>       =20
>>>>
>>>>>Waiting for Wireless Events from interfaces...
>>>>>16:20:27.453588   wlan0    Set Mode:Managed
>>>>>16:20:27.462104   wlan0    Set Encryption key:off
>>>>>16:20:27.463940   wlan0    Set Encryption key:****-****-**   Secur=
ity=20
>>>>>mode:open
>>>>>16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"
>>>>>
>>>>>waiting, nothing else happens. Then run iwlist scan from another
>>>>>terminal.
>>>>>
>>>>>16:20:53.892549   wlan0    Scan request completed
>>>>>    =20
>>>>>         =20
>>>>>
>>>>So you only get this when you manually scan right after setting the=
 ssid
>>>>and key?
>>>>  =20
>>>>       =20
>>>>
>>>If you look at the time stamp, I ran the iwlist scan about 26 second=
s
>>>after loading the module. When the module is loaded, the networking
>>>script sets the essid and encryption key.
>>>
>>>So yes, I only get that 'Scan request completed' line after running
>>>iwlist scan manually.
>>>
>>>=20
>>>     =20
>>>
>>Don't know whether this is related, but I was having all kinds of tro=
uble=20
>>getting associated,
>>iwlist eth1 scan would report no scan results, I then switched to loa=
ding=20
>>the kernel module with
>>the option that tells  iwl3945 to do software scanning and it works=20
>>everytime now.
>>   =20
>>
>
>Which option is that?
>
> =20
>
In my modprobe.conf file:
options iwl3945 disable_hw_scan=3D1

HTH,
Steve

--=20

"They that give up essential liberty to obtain temporary safety,=20
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty=20
decreases."  (Thomas Jefferson)



-
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: [ipw3945-devel] iwl3945 doesn't work

[Johannes Berg]

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

On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote:

> >>iwlist eth1 scan would report no scan results, I then switched to loading 
> >>the kernel module with
> >>the option that tells  iwl3945 to do software scanning and it works 
> >>everytime now.

> In my modprobe.conf file:
> options iwl3945 disable_hw_scan=1

Hah. Told you it wasn't mac80211's problem. Can somebody remind me again
exactly why we have hardware scan offload when we parse each received
packet anyway and the hardware doesn't even batch them so the CPU could
wake up less?

johannes

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

Re: [ipw3945-devel] iwl3945 doesn't work

[Tomas Winkler]

On 10/18/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote:
>
> > >>iwlist eth1 scan would report no scan results, I then switched to loading
> > >>the kernel module with
> > >>the option that tells  iwl3945 to do software scanning and it works
> > >>everytime now.
>
> > In my modprobe.conf file:
> > options iwl3945 disable_hw_scan=1
>
> Hah. Told you it wasn't mac80211's problem. Can somebody remind me again
> exactly why we have hardware scan offload when we parse each received
> packet anyway and the hardware doesn't even batch them so the CPU could
> wake up less?
>
1. Tuning to each channel is done internally by fw so you don't spend
cycles and it's is faster to switch channels so overall scanning take
less time. Sending probe responses is also offloaded.  Returning to
operational channel is more precisely matched to DTIM period as it is
handled by RT code.
2. There are also more advanced modes of scanning such as during voice
traffic etc.
3. Yes beacon batching will be nice, but there is a memory tradeoff.
Tomas

> johannes
>
>

Re: [ipw3945-devel] iwl3945 doesn't work

[Ian Schram]

I wonder if anybody knows something more about this issue by now,
as it appears to occur to a few people.

I reread the thread (rather quickly) but I do not see many specifications
of driver/mac80211/kernel. The few cases that do contain specs all appear
to be using fedora (don't want to jump to conclusions). But just wondering if
anybody experienced this on any other kernel?

The log that I saw from a person with these symptoms, showed a perfectly normal
booting driver, doing all the initialization identical to my functional card,
except that apparently iwl_mac_open() (which is currently known as iwl3945_mac_start iirc)
is never called.

this callback is conditionally called from mac80211, in on it's turn a callback from
even higher up the kernel stack. Hence my best (uneducated) guess would be that
for some reason mac80211 doesn't call the ops->start(), but the scan (completion)
somehow manages to rectify this

I believe this bug is similar though with older versions of the code
http://bughost.org/bugzilla/show_bug.cgi?id=1452
although back then the scan didn't magically fix it.

Seeing as the driver appears to be functioning normally (it's receiving! and dropping
packages because not open). and my knowledge of mac80211 is very limited i'm hoping
someone here knows:

What could sensibly be causing ops->start() not to be called?

Tomas Winkler wrote:
> On 10/18/07, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote:
>>
>>>>> iwlist eth1 scan would report no scan results, I then switched to loading
>>>>> the kernel module with
>>>>> the option that tells  iwl3945 to do software scanning and it works
>>>>> everytime now.
>>> In my modprobe.conf file:
>>> options iwl3945 disable_hw_scan=1
>> Hah. Told you it wasn't mac80211's problem. Can somebody remind me again
>> exactly why we have hardware scan offload when we parse each received
>> packet anyway and the hardware doesn't even batch them so the CPU could
>> wake up less?
>>
> 1. Tuning to each channel is done internally by fw so you don't spend
> cycles and it's is faster to switch channels so overall scanning take
> less time. Sending probe responses is also offloaded.  Returning to
> operational channel is more precisely matched to DTIM period as it is
> handled by RT code.
> 2. There are also more advanced modes of scanning such as during voice
> traffic etc.
> 3. Yes beacon batching will be nice, but there is a memory tradeoff.
> Tomas
> 
>> johannes
>>
>>
> 

Re: [ipw3945-devel] iwl3945 doesn't work

[Ismail Dönmez]

Saturday 10 November 2007 Tarihinde 04:18:27 yazm=C4=B1=C5=9Ft=C4=B1:
> I wonder if anybody knows something more about this issue by now,
> as it appears to occur to a few people.
>
> I reread the thread (rather quickly) but I do not see many specificat=
ions
> of driver/mac80211/kernel. The few cases that do contain specs all ap=
pear
> to be using fedora (don't want to jump to conclusions). But just wond=
ering
> if anybody experienced this on any other kernel?

Btw this is still not fixed in latest git (post rc2).

Regards,
ismail

--=20
=46aith is believing what you know isn't so -- Mark Twain
-
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: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
> Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
> > I wonder if anybody knows something more about this issue by now,
> > as it appears to occur to a few people.
> >
> > I reread the thread (rather quickly) but I do not see many specific=
ations
> > of driver/mac80211/kernel. The few cases that do contain specs all =
appear
> > to be using fedora (don't want to jump to conclusions). But just wo=
ndering
> > if anybody experienced this on any other kernel?
>=20
> Btw this is still not fixed in latest git (post rc2).

I'll second that, using todays snap still requires me to do an iwlist
scan before I can use the network.

Is anyone working on this at all? This was reported a month ago, yet no
progress or real developer interest in fixing this is apparent.

--=20
Jens Axboe

-
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: [ipw3945-devel] iwl3945 doesn't work

[Pablo Sanchez]

On Thursday 15 November 2007 at 4:39 am, Jens Axboe penned
about "Re: [ipw3945-devel] iwl3945 doesn't work:

> I'll second that, using todays snap still requires me to do an
> iwlist scan before I can use the network.

Same here and for now, I've given up on using the Intel card on my
laptop.  I slapped an El Cheapo 3COM card.  While less mW's and
sensitivity, the MadWifi support is awesome for this atheros based
card.

Under stress, my ping times are within 100ms (unlike what I reported
previously), throughput is at 5Mbps and it works well with
KnetworkManager.

I'm not complaining about the Intel support, just noting for now the
problem isn't pressing for me.  I'll happily test new drops as they
come out and address the issues I reported.

I'd appreciate even an acknowledgment though (rather than the old
/dev/null treatment).

Cheers,
-- 
Pablo

Re: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Thu, Nov 15 2007, Pablo Sanchez wrote:
> On Thursday 15 November 2007 at 4:39 am, Jens Axboe penned
> about "Re: [ipw3945-devel] iwl3945 doesn't work:
> 
> > I'll second that, using todays snap still requires me to do an
> > iwlist scan before I can use the network.
> 
> Same here and for now, I've given up on using the Intel card on my
> laptop.  I slapped an El Cheapo 3COM card.  While less mW's and
> sensitivity, the MadWifi support is awesome for this atheros based
> card.
> 
> Under stress, my ping times are within 100ms (unlike what I reported
> previously), throughput is at 5Mbps and it works well with
> KnetworkManager.
> 
> I'm not complaining about the Intel support, just noting for now the
> problem isn't pressing for me.  I'll happily test new drops as they
> come out and address the issues I reported.
> 
> I'd appreciate even an acknowledgment though (rather than the old
> /dev/null treatment).

I'll revert to using ipw3945, it worked flawlessly for me. Hopefully the
iwl3945 driver will work sometime in the future, but as you note, not a
lot of progress appears to be happening. So I wont hold my breath.

-- 
Jens Axboe

Re: [ipw3945-devel] iwl3945 doesn't work

[Pablo Sanchez]

On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
about "Re: [ipw3945-devel] iwl3945 doesn't work:

> I'll revert to using ipw3945, it worked flawlessly for me.
> Hopefully the iwl3945 driver will work sometime in the future, but
> as you note, not a lot of progress appears to be happening. So I
> wont hold my breath.

Hmmm, will that driver work on my Intel PRO 4965 card?

Do you know whether I need to download the different microcode?

I'm all for junking the El Cheapo card.  It's annoying have it blink
at me every second.  :p

Cheers,
-- 
Pablo

Re: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Thu, Nov 15 2007, Pablo Sanchez wrote:
> On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> about "Re: [ipw3945-devel] iwl3945 doesn't work:
> 
> > I'll revert to using ipw3945, it worked flawlessly for me.
> > Hopefully the iwl3945 driver will work sometime in the future, but
> > as you note, not a lot of progress appears to be happening. So I
> > wont hold my breath.
> 
> Hmmm, will that driver work on my Intel PRO 4965 card?

Nope, I think you are out of luck, it only covers 3945ABG only.

> Do you know whether I need to download the different microcode?

I don't know how big the differences between 3945 and 4945 are, but I'd
be surprised if that works. Others here will know more for sure.

> I'm all for junking the El Cheapo card.  It's annoying have it blink
> at me every second.  :p

:-)

-- 
Jens Axboe

Re: [ipw3945-devel] iwl3945 doesn't work

[Mike Kershaw]

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

On Thu, Nov 15, 2007 at 05:30:14AM -0500, Pablo Sanchez wrote:
> On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> about "Re: [ipw3945-devel] iwl3945 doesn't work:
> 
> > I'll revert to using ipw3945, it worked flawlessly for me.
> > Hopefully the iwl3945 driver will work sometime in the future, but
> > as you note, not a lot of progress appears to be happening. So I
> > wont hold my breath.
> 
> Hmmm, will that driver work on my Intel PRO 4965 card?

No, but iwl4965 from the same driver tree will.

> Do you know whether I need to download the different microcode?

Yes.

http://intellinuxwireless.org

-m

-- 
Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

Todays lesson is always to ignore your feelings and listen to the robot head.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Thu, Nov 15 2007, Mike Kershaw wrote:
> On Thu, Nov 15, 2007 at 05:30:14AM -0500, Pablo Sanchez wrote:
> > On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> > about "Re: [ipw3945-devel] iwl3945 doesn't work:
> > 
> > > I'll revert to using ipw3945, it worked flawlessly for me.
> > > Hopefully the iwl3945 driver will work sometime in the future, but
> > > as you note, not a lot of progress appears to be happening. So I
> > > wont hold my breath.
> > 
> > Hmmm, will that driver work on my Intel PRO 4965 card?
> 
> No, but iwl4965 from the same driver tree will.

Ehm, I'd be surprised if Pablo didn't mean if ipw3945 would work with
his card, not iwl3945.

-- 
Jens Axboe

Re: [ipw3945-devel] iwl3945 doesn't work

[Pablo Sanchez]

On Thursday 15 November 2007 at 10:05 am, Mike Kershaw penned
about "Re: [ipw3945-devel] iwl3945 doesn't work:

> On Thu, Nov 15, 2007 at 05:30:14AM -0500, Pablo Sanchez wrote:
> > On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> >
> > about "Re: [ipw3945-devel] iwl3945 doesn't work:
> > > I'll revert to using ipw3945, it worked flawlessly for me.
> > > Hopefully the iwl3945 driver will work sometime in the future,
> > > but as you note, not a lot of progress appears to be happening.
> > > So I wont hold my breath.
> >
> > Hmmm, will that driver work on my Intel PRO 4965 card?
>
> No, but iwl4965 from the same driver tree will.

I think you jumped into the thread.  The iwl4965 driver is covered by
iwlwifi and that's the driver which I've reported a couple of issues.
So far, no word from Intel.  Hence why I'm using 'blinky'

blinky - a 3COM card which blinks once a second.

Cheers,
-- 
Pablo

Re: [ipw3945-devel] iwl3945 doesn't work

[John W. Linville]

On Thu, Nov 15, 2007 at 10:39:22AM +0100, Jens Axboe wrote:
> On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
> > Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
> > > I wonder if anybody knows something more about this issue by now,
> > > as it appears to occur to a few people.
> > >
> > > I reread the thread (rather quickly) but I do not see many specif=
ications
> > > of driver/mac80211/kernel. The few cases that do contain specs al=
l appear
> > > to be using fedora (don't want to jump to conclusions). But just =
wondering
> > > if anybody experienced this on any other kernel?
> >=20
> > Btw this is still not fixed in latest git (post rc2).
>=20
> I'll second that, using todays snap still requires me to do an iwlist
> scan before I can use the network.
>=20
> Is anyone working on this at all? This was reported a month ago, yet =
no
> progress or real developer interest in fixing this is apparent.

I don't see any pending patches that seem relevant.  FWIW I'll probably
round-up what I do have and make them available today (and probably
in a Fedora kernel too).

Does the disable_hw_scan=3D1 still work for you?  Perhaps we should
consider making that the default...

John
--=20
John W. Linville
linville@tuxdriver.com
-
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: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Thu, Nov 15 2007, John W. Linville wrote:
> On Thu, Nov 15, 2007 at 10:39:22AM +0100, Jens Axboe wrote:
> > On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
> > > Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
> > > > I wonder if anybody knows something more about this issue by no=
w,
> > > > as it appears to occur to a few people.
> > > >
> > > > I reread the thread (rather quickly) but I do not see many spec=
ifications
> > > > of driver/mac80211/kernel. The few cases that do contain specs =
all appear
> > > > to be using fedora (don't want to jump to conclusions). But jus=
t wondering
> > > > if anybody experienced this on any other kernel?
> > >=20
> > > Btw this is still not fixed in latest git (post rc2).
> >=20
> > I'll second that, using todays snap still requires me to do an iwli=
st
> > scan before I can use the network.
> >=20
> > Is anyone working on this at all? This was reported a month ago, ye=
t no
> > progress or real developer interest in fixing this is apparent.
>=20
> I don't see any pending patches that seem relevant.  FWIW I'll probab=
ly
> round-up what I do have and make them available today (and probably
> in a Fedora kernel too).
>=20
> Does the disable_hw_scan=3D1 still work for you?  Perhaps we should
> consider making that the default...

disable_hw_scan=3D1 never worked for me - I tried it, and it made no
difference. I _have_ to do an iwlist wlan0 scan before it links with my
access point, otherwise it doesn't work.

--=20
Jens Axboe

-
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: [ipw3945-devel] iwl3945 doesn't work

[Ian Schram]

I believe that a main problem is that people have trouble reproducing i=
t.
and despite my -somewhat- implicit question there is not more informati=
on
in this thread now. Other than some symptoms. It would probably help if=
 you
posted system/software specifications and debug info to a (new) bug ove=
r at
bughost.org. (modprobe iwl3945 debug=3D0x43fff) to allow for it to be t=
racked better?

Because now imho we are just poking at it with a medium length stick.

With the information here, I honestly have no idea where to look, other=
s might
have the same problem.

ian

Jens Axboe wrote:
> On Thu, Nov 15 2007, John W. Linville wrote:
>> On Thu, Nov 15, 2007 at 10:39:22AM +0100, Jens Axboe wrote:
>>> On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
>>>> Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
>>>>> I wonder if anybody knows something more about this issue by now,
>>>>> as it appears to occur to a few people.
>>>>>
>>>>> I reread the thread (rather quickly) but I do not see many specif=
ications
>>>>> of driver/mac80211/kernel. The few cases that do contain specs al=
l appear
>>>>> to be using fedora (don't want to jump to conclusions). But just =
wondering
>>>>> if anybody experienced this on any other kernel?
>>>> Btw this is still not fixed in latest git (post rc2).
>>> I'll second that, using todays snap still requires me to do an iwli=
st
>>> scan before I can use the network.
>>>
>>> Is anyone working on this at all? This was reported a month ago, ye=
t no
>>> progress or real developer interest in fixing this is apparent.
>> I don't see any pending patches that seem relevant.  FWIW I'll proba=
bly
>> round-up what I do have and make them available today (and probably
>> in a Fedora kernel too).
>>
>> Does the disable_hw_scan=3D1 still work for you?  Perhaps we should
>> consider making that the default...
>=20
> disable_hw_scan=3D1 never worked for me - I tried it, and it made no
> difference. I _have_ to do an iwlist wlan0 scan before it links with =
my
> access point, otherwise it doesn't work.
>=20
-
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: [ipw3945-devel] iwl3945 doesn't work

[Jens Axboe]

On Thu, Oct 18 2007, Stephen Clark wrote:
> Jens Axboe wrote:
>
>> On Wed, Oct 17 2007, Stephen Clark wrote:
>> =20
>>> Jens Axboe wrote:
>>>
>>>   =20
>>>> On Wed, Oct 17 2007, Dan Williams wrote:
>>>>     =20
>>>>> On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>>>>         =20
>>>>>> On Wed, Oct 17 2007, Dan Williams wrote:
>>>>>>             =20
>>>>>>> On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>>>>                 =20
>>>>>>>> On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>>>>                     =20
>>>>>>>>> Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>>>>                         =20
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Seeing that iwl3945 is now merged, I decided to switch my x6=
0 to=20
>>>>>>>>>> use
>>>>>>>>>> that instead of ipw3945. That would leave me with zero kerne=
l
>>>>>>>>>> dependencies.
>>>>>>>>>>
>>>>>>>>>> Unfortunately it doesn't work. Loading the module reveals th=
e=20
>>>>>>>>>> device:
>>>>>>>>>>
>>>>>>>>>> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection=
=20
>>>>>>>>>> driver for
>>>>>>>>>> Linux, 1.1.17ks
>>>>>>>>>> iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>>>> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -=
> IRQ=20
>>>>>>>>>> 21
>>>>>>>>>> PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>>>> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connect=
ion
>>>>>>>>>> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>>>> phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>>>>
>>>>>>>>>> # iwconfig wlan0
>>>>>>>>>> wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"
>>>>>>>>>>         Mode:Managed  Channel:0  Access Point: Not-Associate=
d
>>>>>>>>>>         Tx-Power=3D0 dBm
>>>>>>>>>>         Retry min limit:7   RTS thr:off   Fragment thr=3D234=
6 B
>>>>>>>>>>         Encryption key:XXXX-XXXX-XX
>>>>>>>>>>         Link Quality:0  Signal level:0  Noise level:0
>>>>>>>>>>         Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid fr=
ag:0
>>>>>>>>>>         Tx excessive retries:0  Invalid misc:0   Missed beac=
on:0
>>>>>>>>>>
>>>>>>>>>> and iwconfig sees it, essid/enc settings are fine, but I don=
't get=20
>>>>>>>>>> a
>>>>>>>>>> link.
>>>>>>>>>>                             =20
>>>>>>>>> Same issue here, try iwlist wlan0 scan first and then it shou=
ld=20
>>>>>>>>> work.
>>>>>>>>>                         =20
>>>>>>>> Huh indeed, now it links fine! Thanks for the hint. Would be n=
ice to
>>>>>>>> have fixed, though :-)
>>>>>>>>                     =20
>>>>>>> Odd, doesn't the driver need to do a scan _anyway_ to find the =
right
>>>>>>> BSSID to associate with if the cached scan results are more tha=
n a=20
>>>>>>> few
>>>>>>> seconds old?  Can you run '/sbin/iwevent' before trying a fresh
>>>>>>> association, try to associate, ensure that it has failed, and r=
eport=20
>>>>>>> the
>>>>>>> output?
>>>>>>>
>>>>>>> If you don't get something like:
>>>>>>>
>>>>>>> 10:17:05.117937   eth1     Scan request completed
>>>>>>>
>>>>>>> shown there, then there's likely a bug in the driver because it=
's=20
>>>>>>> either
>>>>>>> (a) not scanning before trying to associate, or (b) not sending=
 out=20
>>>>>>> scan
>>>>>>> completion events after it's done a scan.
>>>>>>>                 =20
>>>>>> Indeed, there is now Scan request completed before I run the iwl=
ist
>>>>>> scan. iwevent output:
>>>>>>             =20
>>>>> Hmm, the output below doesn't show the scan request completed, ri=
ght?
>>>>>
>>>>>         =20
>>>>>> Waiting for Wireless Events from interfaces...
>>>>>> 16:20:27.453588   wlan0    Set Mode:Managed
>>>>>> 16:20:27.462104   wlan0    Set Encryption key:off
>>>>>> 16:20:27.463940   wlan0    Set Encryption key:****-****-**   Sec=
urity=20
>>>>>> mode:open
>>>>>> 16:20:27.466535   wlan0    Set ESSID:"kjellbergaxboe"
>>>>>>
>>>>>> waiting, nothing else happens. Then run iwlist scan from another
>>>>>> terminal.
>>>>>>
>>>>>> 16:20:53.892549   wlan0    Scan request completed
>>>>>>             =20
>>>>> So you only get this when you manually scan right after setting t=
he=20
>>>>> ssid
>>>>> and key?
>>>>>         =20
>>>> If you look at the time stamp, I ran the iwlist scan about 26 seco=
nds
>>>> after loading the module. When the module is loaded, the networkin=
g
>>>> script sets the essid and encryption key.
>>>>
>>>> So yes, I only get that 'Scan request completed' line after runnin=
g
>>>> iwlist scan manually.
>>>>
>>>>     =20
>>> Don't know whether this is related, but I was having all kinds of t=
rouble=20
>>> getting associated,
>>> iwlist eth1 scan would report no scan results, I then switched to l=
oading=20
>>> the kernel module with
>>> the option that tells  iwl3945 to do software scanning and it works=
=20
>>> everytime now.
>>>   =20
>>
>> Which option is that?
>>
>> =20
> In my modprobe.conf file:
> options iwl3945 disable_hw_scan=3D1

That option is already set here:

carl:/etc/modprobe.d # grep . iwlwifi=20
options iwl3945 disable_hw_scan=3D1
options iwl4965 disable_hw_scan=3D1

--=20
Jens Axboe

-
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: iwl3945 doesn't work

[Dan Williams]

On Wed, 2007-10-17 at 15:54 +0200, Jens Axboe wrote:
> Hi,
> 
> Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> that instead of ipw3945. That would leave me with zero kernel
> dependencies.
> 
> Unfortunately it doesn't work. Loading the module reveals the device:
> 
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
> 
> # iwconfig wlan0
> wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"  
>           Mode:Managed  Channel:0  Access Point: Not-Associated   
>           Tx-Power=0 dBm   
>           Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
>           Encryption key:XXXX-XXXX-XX
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.

You do have the updated firmware, right?  I don't think iwl3945 would
even load if you didn't, but it doesn't hurt to check.

Also, what exact kernel version are you using?  2.6.23 release kernel?
Or something from development series?

Dan

Re: iwl3945 doesn't work

[Jens Axboe]

On Wed, Oct 17 2007, Dan Williams wrote:
> On Wed, 2007-10-17 at 15:54 +0200, Jens Axboe wrote:
> > Hi,
> > 
> > Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> > that instead of ipw3945. That would leave me with zero kernel
> > dependencies.
> > 
> > Unfortunately it doesn't work. Loading the module reveals the device:
> > 
> > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> > Linux, 1.1.17ks
> > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > 
> > # iwconfig wlan0
> > wlan0     IEEE 802.11g  ESSID:"xxxxxxxxxxxxxx"  
> >           Mode:Managed  Channel:0  Access Point: Not-Associated   
> >           Tx-Power=0 dBm   
> >           Retry min limit:7   RTS thr:off   Fragment thr=2346 B   
> >           Encryption key:XXXX-XXXX-XX
> >           Link Quality:0  Signal level:0  Noise level:0
> >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
> >           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> > 
> > and iwconfig sees it, essid/enc settings are fine, but I don't get a
> > link.
> 
> You do have the updated firmware, right?  I don't think iwl3945 would
> even load if you didn't, but it doesn't hurt to check.

I'm using the suse firmware package, it claims to be version 2.14.1.5.

> Also, what exact kernel version are you using?  2.6.23 release kernel?
> Or something from development series?

It's -git as of last night, so current 2.6.23-git.

As per the last hint, using iwlist scan wlan0 makes it work. I'd prefer
it it worked out of the box, though :-)

-- 
Jens Axboe

Re: iwl3945 doesn't work

[bmoss]

I have observed that 'iwlist wlan0 scan' sometimes fails to produce a scan
and manual configuration with iwconfig sometimes fails to produce an
association. I also observed that the Fedora 8 configuration script issues
the command 'ip link set wlan0 up' before configuring the wlan0 and it
always works. I also noted in the Intel documentation that the command
'ifconfig wlan0 up' should be issued before configuing the wlan0. For
manual configuration, I now use

ifconfig wlan0 up
ip link set wlan0 up
iwconfig wlan0 mode Managed
iwconfig wlan0 key xxxxxxxxxxxxxxxxxxxxxxxxxx
iwconfig wlan0 essid mosswap
dhclient wlan0

It always works.

I believe the iwl3945 driver is broken when there are hidden AP's in the
scan list. It appears that the scan list returned to wpa_supplicant is
corrupted which is why the wpa_supplicant setting ap_scan=2 does not for
hidden AP's.

With hardware scanning enabled as a module option, it appears that iwl3945
does both a background scan and a scan by ssid when the ssid is set unlike
ipw2200 which does background scans constantly and only does scan by ssid
when it is requested.

Bill Moss