LinuxLists.cc - iwl4965 - wpa_supplicant can't see 5Ghz frequencies

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> I guess the better solution would be to handle A-band channels too. Is
> there a canonical mapping of channel # to frequency somewhere for the
> A-band stuff? I put together the following table a while ago from
> googling around which is probably the wrong way to do it, but... my
> sources were mainly wikipedia channel maps for 802.11a and some cisco
> docs from somewhere.

Well if you ignore 802.11j (now merged into 802.11-2007) then it's just
(chan + 1000) * 5.

johannes

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2008-05-22 19:13:59

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> > wpa_supplicant cannot handle A-band channel #s. Thus, with the previous
> > code, the FREQ+frequency was sent first, and the FREQ+channel was sent
> > second. Sending the FREQ+channel second made the supplicant overwrite
> > the value it already parsed from the FREQ+frequency for that BSSID. But
> > since the supplicant can't handle A-band channel #s, you end up with 0.
> >
> > Reversing the order of these two makes it work, but it's a total hack.
> > That may be what's needed right now though until everyone fixes their
> > supplicant. There's overlap on A-band channels 7 - 12 (5035MHz ->
> > 5060MHz) with B/G band channel #s. Obviously WEXT falls over here
> > because the band isn't passed.
> >
> > But what's the best fix to the supplicant? It could just parse A-band
> > channels and where the numbers overlap, assume B/G band. Or, it could
> > be patched to prefer FREQ+frequency over FREQ+channel if it received
> > both. That's probably the best solution.

Fun. How about it we just make wpa supplicant ignore FREQ/channel
completely if it uses FREQ/frequency anyway?

> Actually we've also tried to removing FREQ+channel part and it has
> worked. So wpa_supplicant won't get into this dilemma.

Makes sense.

> Patch that broke it is below so I guess the bug is in everything form
> 2.6.25 and up.
> '
> commit 8318d78a44d49ac1edf2bdec7299de3617c4232e
> Author: Johannes Berg <[email protected]>
> Date: Thu Jan 24 19:38:38 2008 +0100
>
> cfg80211 API for channels/bitrates, mac80211 and driver conversion
> '

Yeah, sorry about that. Once more, bitten by the assumption wext was
useful and people would implement it properly.

johannes

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2008-05-10 17:06:58

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sat, May 10, 2008 at 5:39 PM, Vincent C Jones
<[email protected]> wrote:
>
> On Sat, 2008-05-10 at 03:12 +0300, Tomas Winkler wrote:
>> On Sat, May 10, 2008 at 2:41 AM, Vincent C Jones
>> <[email protected]> wrote:
>> >
>> > On Sat, 2008-05-10 at 00:23 +0300, Tomas Winkler wrote:
>> >> On Fri, May 9, 2008 at 7:57 PM, Vincent C Jones
>> >> <[email protected]> wrote:
>> >> > The channel/frequency reporting by iwlwifi is incompatible with
>> >> > wpa_supplicant for 5GHz (802.11A) channels. Version numbers and iwlist
>> >> > versus wpa_supplicant scan results are below. Association still works if
>> >> > the correct channel is specified using iwconfig, but that is
>> >> > incompatible with roaming.
>> >>
>> >> Fixed by the patch ' iwlwifi: Fix frequency in rx_status fill'
>> >>
>> >> Thanks
>> >> Tomas
>> >
>> > This patch did not apply cleanly to plain 2.6.26-rc1: off by -4 lines in
>> > iwl-3945.c and by 1078 lines in iwl-4965.c. More important, it did not
>> > fix the problem of wpa_supplicant thinking the 802.11A access points are
>> > on channel 0. Same results with 2.6.26-rc1-git7, with & without patch.
>> > Any idea when this patch (and the patches it appears to depend on) will
>> > make it into the 2.6.26 release?
>> >
>>
>> This patch is against wireless-testing.git, it's just too lines and
>> doesn't really have logical dependencies on other patches so I didn't
>> create a separate patch for 2.6.26...It looks maybe I should.
>> Can you try to eproduce your problem on wireless-testing kernel with
>> this patch?
>> Also some logs will be useful
>>
>> Thanks
>> Tomas
>
> Tomas,
>
> No joy. Did I git the wrong tree?
>
> (git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git)
>
> Still had to apply your patch (offset 223 lines this time). Also applied
> the media/built-in.o patch so my config would compile. Wpa_supplicant
> (v0.6.3) still reports 0 for the channel of 11A stations:

It seems to be correct. There are some patches that come before this
one yet Yi has reordered the series a bit and pushed this one first
because of it's urgency. The later patches will come later, but there
is no dependency. So that my explain the offset.

>> scan_res
> bssid / frequency / signal level / flags / ssid
> 00:1a:c1:8a:23:40 0 208 [WPA-PSK-TKIP
> +CCMP][WPA2-PSK-TKIP+CCMP-preauth] NetworkingUnlimited
> 00:1e:2a:6c:93:d9 2462 169 [WPA-PSK-TKIP
> +CCMP][WPA2-PSK-TKIP+CCMP]NetworkingUnlimited-G
>>
>
> I've appended output of iwlist scan and dmesg. Any other logs of
> interest?
>
>
> Cell 05 - Address: 00:1A:C1:8A:23:40
> ESSID:"NetworkingUnlimited"
> Mode:Master
> Frequency:5.24 GHz (Channel 48)
> Channel:48

Looks like channel is reported correctly here

>>>>> issue command "iwconfig wlan0 chan 48"

Not sure how wpa supplicant parses the scanning output

The scan result is build by ieee80211_sta_scan_result function
defined in mlme.c file

The code dealing with frequency is below. I currently I don't have 11a
AP so if you can put some debug output in wpa_supplicant and mac80211
we can learn more. Otherwise I will have to look at this tomorrow

memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
iwe.u.freq.m = bss->freq;
iwe.u.freq.e = 6;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);

memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
iwe.u.freq.e = 0;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);

Thanks
Tomas

2008-05-22 19:30:19

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 21:12 +0200, Johannes Berg wrote:
> > > wpa_supplicant cannot handle A-band channel #s. Thus, with the previous
> > > code, the FREQ+frequency was sent first, and the FREQ+channel was sent
> > > second. Sending the FREQ+channel second made the supplicant overwrite
> > > the value it already parsed from the FREQ+frequency for that BSSID. But
> > > since the supplicant can't handle A-band channel #s, you end up with 0.
> > >
> > > Reversing the order of these two makes it work, but it's a total hack.
> > > That may be what's needed right now though until everyone fixes their
> > > supplicant. There's overlap on A-band channels 7 - 12 (5035MHz ->
> > > 5060MHz) with B/G band channel #s. Obviously WEXT falls over here
> > > because the band isn't passed.
> > >
> > > But what's the best fix to the supplicant? It could just parse A-band
> > > channels and where the numbers overlap, assume B/G band. Or, it could
> > > be patched to prefer FREQ+frequency over FREQ+channel if it received
> > > both. That's probably the best solution.
>
> Fun. How about it we just make wpa supplicant ignore FREQ/channel
> completely if it uses FREQ/frequency anyway?

Can't because some drivers send channel and not frequency. Yeah, we
could fix all the drivers, but that doesn't help people running latest
supplicant on older kernels.

atmel.c
zd1201.c
wl3501_cs.c
linux-wlan-ng (somewhat unclear but probably)

Dan

> > Actually we've also tried to removing FREQ+channel part and it has
> > worked. So wpa_supplicant won't get into this dilemma.
>
> Makes sense.
>
> > Patch that broke it is below so I guess the bug is in everything form
> > 2.6.25 and up.
> > '
> > commit 8318d78a44d49ac1edf2bdec7299de3617c4232e
> > Author: Johannes Berg <[email protected]>
> > Date: Thu Jan 24 19:38:38 2008 +0100
> >
> > cfg80211 API for channels/bitrates, mac80211 and driver conversion
> > '
>
> Yeah, sorry about that. Once more, bitten by the assumption wext was
> useful and people would implement it properly.
>
> johannes

2008-05-10 18:56:29

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

>
> May be more to this than just missing 802.11a channel reporting...
> walked to within range of a NetGear dual-band 802.11N 5GHz/11G 2.4GHz AP
> and could not even see the 802.11A side of the AP, (while another
> machine was associated with it, so both halves of the AP were up).
> I associated on the G channel, then tried to force an association on the
> A channel by setting the frequency with iwconfig. At some point, I got
> the following (note that I could still associate with the G channel when
> done):
>
> ay 10 11:20:04 X61 kernel: ------------[ cut here ]------------
> May 10 11:20:04 X61 kernel: WARNING: at
> include/../net/mac80211/rate.h:153 rs_get_rate+0x159/0x194 [iwl4965]()

Something went wrong with station management. Do you use same BSSID
on the both interfaces A and G?

Thanks
Tomas

2008-05-22 22:33:38

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 19:53 +0300, Tomas Winkler wrote:
> On Mon, May 12, 2008 at 9:37 PM, Vincent C Jones
> <[email protected]> wrote:
> >
> > On Mon, 2008-05-12 at 19:50 +0300, Tomas Winkler wrote:
> >
> >> Meanwhile we've reproduced the wpa_supplicant issue...
> >>
> >
> > That is great news. Let me know when it is time to test again...
>
> Please try this one. I've just pasted that in so it's might be
> white-space-wise broken
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 7877d3b..5996e3d 100644
> * * *
> Tomas

Tomas,

Applied patch to today's
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
and I can confirm that wpa_supplicant v0.6.3 again works on the A band.

FWIW, however, I still have some issues:

1 - Roaming from 3com to NetGear takes about 5 minutes before iwlist
scan sees the A/N channel on the NetGear AP. Roaming from NetGear to
3com, however, the 3com AP is seen on the first scan after losing
contact.

2 - The NetGear is allegedly 11n, but shows up as standard A (or G) in
iwconfig et al. Highest data rate listed by iwlist is 54 on A, 48 on G.

3 - Booting Windows, the 4965 does see the NetGear as 802.11n, so I
can't blame it on the hardware...

4 - I won't guarantee it is not a configuration issue on my part...
attached is the ".config" file used to compile the kernel.

As always, let me know if there are any other tests I can run or
traces/logs I could collect which would help determine what is going on
here.

Vince

Attachments:

DOTconfig (75.23 kB)

2008-05-10 14:39:44

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sat, 2008-05-10 at 03:12 +0300, Tomas Winkler wrote:
> On Sat, May 10, 2008 at 2:41 AM, Vincent C Jones
> <[email protected]> wrote:
> >
> > On Sat, 2008-05-10 at 00:23 +0300, Tomas Winkler wrote:
> >> On Fri, May 9, 2008 at 7:57 PM, Vincent C Jones
> >> <[email protected]> wrote:
> >> > The channel/frequency reporting by iwlwifi is incompatible with
> >> > wpa_supplicant for 5GHz (802.11A) channels. Version numbers and iwlist
> >> > versus wpa_supplicant scan results are below. Association still works if
> >> > the correct channel is specified using iwconfig, but that is
> >> > incompatible with roaming.
> >>
> >> Fixed by the patch ' iwlwifi: Fix frequency in rx_status fill'
> >>
> >> Thanks
> >> Tomas
> >
> > This patch did not apply cleanly to plain 2.6.26-rc1: off by -4 lines in
> > iwl-3945.c and by 1078 lines in iwl-4965.c. More important, it did not
> > fix the problem of wpa_supplicant thinking the 802.11A access points are
> > on channel 0. Same results with 2.6.26-rc1-git7, with & without patch.
> > Any idea when this patch (and the patches it appears to depend on) will
> > make it into the 2.6.26 release?
> >
>
> This patch is against wireless-testing.git, it's just too lines and
> doesn't really have logical dependencies on other patches so I didn't
> create a separate patch for 2.6.26...It looks maybe I should.
> Can you try to eproduce your problem on wireless-testing kernel with
> this patch?
> Also some logs will be useful
>
> Thanks
> Tomas

Tomas,

No joy. Did I git the wrong tree?

(git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git)

Still had to apply your patch (offset 223 lines this time). Also applied
the media/built-in.o patch so my config would compile. Wpa_supplicant
(v0.6.3) still reports 0 for the channel of 11A stations:

> scan_res
bssid / frequency / signal level / flags / ssid
00:1a:c1:8a:23:40 0 208 [WPA-PSK-TKIP
+CCMP][WPA2-PSK-TKIP+CCMP-preauth] NetworkingUnlimited
00:1e:2a:6c:93:d9 2462 169 [WPA-PSK-TKIP
+CCMP][WPA2-PSK-TKIP+CCMP]NetworkingUnlimited-G
>

I've appended output of iwlist scan and dmesg. Any other logs of
interest?

Cell 05 - Address: 00:1A:C1:8A:23:40
ESSID:"NetworkingUnlimited"
Mode:Master
Frequency:5.24 GHz (Channel 48)
Channel:48
Quality=95/100 Signal level=-56 dBm Noise
level=-94 dBm
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : TKIP CCMP
Authentication Suites (1) : PSK
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : TKIP CCMP
Authentication Suites (1) : PSK
Preauthentication Supported
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Extra:tsf=000000eefc735037

Abridged dmesg:
Linux version 2.6.26-rc1-wl-test (vcjones@X61) (gcc version 4.2.1 (SUSE
Linux)) #2 SMP Sat May 10 10:12:36 EDT 2008
Command line: root=/dev/disk/by-id/scsi-SATA_ST9160824AS_5MA6SYPF-part6
vga=0x317 resume=/dev/sda7 splash=silent PROFILE=NUI_HQ
. . .
thinkpad_acpi: ThinkPad ACPI Extras v0.20
thinkpad_acpi: http://ibm-acpi.sf.net/
thinkpad_acpi: ThinkPad BIOS 7NETB1WW (2.11 ), EC 7MHT25WW-1.03
thinkpad_acpi: Lenovo ThinkPad X61, model 7675CTO
thinkpad_acpi: radio switch found; radios are enabled
. . .
agpgart: Detected an Intel 965GM Chipset.
agpgart: Detected 7676K stolen memory.
input: ThinkPad Extra Buttons as /class/input/input5
agpgart: AGP aperture is 256M @ 0xe0000000
ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:19.0 to 64
iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.26ks
iwl4965: Copyright(c) 2003-2008 Intel Corporation
eth0: (PCI Express:2.5GB/s:Width x1) 00:16:d3:c4:11:e5
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 4, PHY: 6, PBA No: ffffff-0ff
ICH8M: IDE controller (0x8086:0x2850 rev 0x03) at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[C] -> GSI 16 (level, low) -> IRQ 16
ICH8M: not 100% native mode: will probe irqs later
ICH8M: IDE port disabled
ide0: BM-DMA at 0x18e0-0x18e7
Probing IDE interface ide0...
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0016d3ffffc411e5]
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:03:00.0 to 64
iwl4965: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwl4965: Tunable channels: 11 802.11bg, 13 802.11a channels
phy0: Selected rate control algorithm 'iwl-4965-rs'
ACPI: PCI interrupt for device 0000:03:00.0 disabled
input: 4965AGN as /class/input/input6
hdaps: supported laptop not found!
hdaps: driver init failed (ret=-19)!
thinkpad_ec: thinkpad_ec 0.37 loaded.
tp_smapi 0.37 loading...
tp_smapi successfully loaded (smapi_port=0xb2).
Adding 5246600k swap on /dev/sda7. Priority:-1 extents:1
across:5246600k
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised:
[email protected]
loop: module loaded
fuse init (API version 7.9)
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: sda8: found reiserfs format "3.6" with standard journal
ReiserFS: sda8: using ordered data mode
ReiserFS: sda8: journal params: device sda8, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: sda8: checking transaction log (sda8)
ReiserFS: sda8: Using r5 hash to sort names
firmware: requesting intel-ucode/06-0f-0b
firmware: requesting intel-ucode/06-0f-0b
IA-32 Microcode Update Driver: v1.14a <[email protected]>
Bluetooth: L2CAP ver 2.9
Bluetooth: L2CAP socket layer initialized
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PM: Writing back config space on device 0000:03:00.0 at offset 1 (was
40100102, writing 40100106)
firmware: requesting iwlwifi-4965-1.ucode
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
NET: Registered protocol family 17
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:02.0 to 64
[drm] Initialized i915 1.6.0 20060119 on minor 0
mtrr: type mismatch for e0000000,10000000 old: write-back new:
write-combining
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
input: /usr/sbin/acpi-keys as /class/input/input7
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
<end of dmesg at boot time>

>>>> issue command "iwconfig wlan0 chan 48"

wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:1a:c1:8a:23:40
wlan0: RX authentication from 00:1a:c1:8a:23:40 (alg=0 transaction=2
status=0)
wlan0: authenticated
wlan0: associate with AP 00:1a:c1:8a:23:40
wlan0: RX AssocResp from 00:1a:c1:8a:23:40 (capab=0x11 status=0 aid=1)
wlan0: associated

2008-05-22 19:35:52

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> > Fun. How about it we just make wpa supplicant ignore FREQ/channel
> > completely if it uses FREQ/frequency anyway?
>
> Can't because some drivers send channel and not frequency. Yeah, we
> could fix all the drivers, but that doesn't help people running latest
> supplicant on older kernels.

Oh, good point. I guess the patch you posted is the only sane thing to
do then, and require that drivers that work in the 5 GHz band send
frequency (because there channel numbers need not be unique due to
802.11j's channelisation offset)

johannes

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2008-05-10 21:48:33

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sat, 2008-05-10 at 21:56 +0300, Tomas Winkler wrote:
> >
> > May be more to this than just missing 802.11a channel reporting...
> > walked to within range of a NetGear dual-band 802.11N 5GHz/11G 2.4GHz AP
> > and could not even see the 802.11A side of the AP, (while another
> > machine was associated with it, so both halves of the AP were up).
> > I associated on the G channel, then tried to force an association on the
> > A channel by setting the frequency with iwconfig. At some point, I got
> > the following (note that I could still associate with the G channel when
> > done):
> >
> > ay 10 11:20:04 X61 kernel: ------------[ cut here ]------------
> > May 10 11:20:04 X61 kernel: WARNING: at
> > include/../net/mac80211/rate.h:153 rs_get_rate+0x159/0x194 [iwl4965]()
>
> Something went wrong with station management. Do you use same BSSID
> on the both interfaces A and G?
>
> Thanks
> Tomas

No.
1st Floor-NetGear Dual Band AGN A/N on 36, BSSID = NetworkingUnlimited
G on 11, BSSID = NetworkingUnlimited-G
2nd Floor - 3Com POE A/G in A modeA on 48, BSSID = NetworkingUnlimited

2008-05-10 00:12:29

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sat, May 10, 2008 at 2:41 AM, Vincent C Jones
<[email protected]> wrote:
>
> On Sat, 2008-05-10 at 00:23 +0300, Tomas Winkler wrote:
>> On Fri, May 9, 2008 at 7:57 PM, Vincent C Jones
>> <[email protected]> wrote:
>> > The channel/frequency reporting by iwlwifi is incompatible with
>> > wpa_supplicant for 5GHz (802.11A) channels. Version numbers and iwlist
>> > versus wpa_supplicant scan results are below. Association still works if
>> > the correct channel is specified using iwconfig, but that is
>> > incompatible with roaming.
>>
>> Fixed by the patch ' iwlwifi: Fix frequency in rx_status fill'
>>
>> Thanks
>> Tomas
>
> This patch did not apply cleanly to plain 2.6.26-rc1: off by -4 lines in
> iwl-3945.c and by 1078 lines in iwl-4965.c. More important, it did not
> fix the problem of wpa_supplicant thinking the 802.11A access points are
> on channel 0. Same results with 2.6.26-rc1-git7, with & without patch.
> Any idea when this patch (and the patches it appears to depend on) will
> make it into the 2.6.26 release?
>

This patch is against wireless-testing.git, it's just too lines and
doesn't really have logical dependencies on other patches so I didn't
create a separate patch for 2.6.26...It looks maybe I should.
Can you try to eproduce your problem on wireless-testing kernel with
this patch?
Also some logs will be useful

Thanks
Tomas

> Vince
>

2008-05-22 20:56:48

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, May 22, 2008 at 10:34 PM, Johannes Berg
<[email protected]> wrote:
>
>> > Fun. How about it we just make wpa supplicant ignore FREQ/channel
>> > completely if it uses FREQ/frequency anyway?
>>
>> Can't because some drivers send channel and not frequency. Yeah, we
>> could fix all the drivers, but that doesn't help people running latest
>> supplicant on older kernels.
>
> Oh, good point. I guess the patch you posted is the only sane thing to
> do then, and require that drivers that work in the 5 GHz band send
> frequency (because there channel numbers need not be unique due to
> 802.11j's channelisation offset)
>

Fix in the mac should go in as well in so it will work with older
supplicants and it doesn't really hurt.
Tomas

2008-05-09 23:41:16

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sat, 2008-05-10 at 00:23 +0300, Tomas Winkler wrote:
> On Fri, May 9, 2008 at 7:57 PM, Vincent C Jones
> <[email protected]> wrote:
> > The channel/frequency reporting by iwlwifi is incompatible with
> > wpa_supplicant for 5GHz (802.11A) channels. Version numbers and iwlist
> > versus wpa_supplicant scan results are below. Association still works if
> > the correct channel is specified using iwconfig, but that is
> > incompatible with roaming.
>
> Fixed by the patch ' iwlwifi: Fix frequency in rx_status fill'
>
> Thanks
> Tomas

This patch did not apply cleanly to plain 2.6.26-rc1: off by -4 lines in
iwl-3945.c and by 1078 lines in iwl-4965.c. More important, it did not
fix the problem of wpa_supplicant thinking the 802.11A access points are
on channel 0. Same results with 2.6.26-rc1-git7, with & without patch.
Any idea when this patch (and the patches it appears to depend on) will
make it into the 2.6.26 release?

Vince

2008-05-22 16:53:55

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Mon, May 12, 2008 at 9:37 PM, Vincent C Jones
<[email protected]> wrote:
>
> On Mon, 2008-05-12 at 19:50 +0300, Tomas Winkler wrote:
>
>> Meanwhile we've reproduced the wpa_supplicant issue...
>>
>
> That is great news. Let me know when it is time to test again...

Please try this one. I've just pasted that in so it's might be
white-space-wise broken

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 7877d3b..5996e3d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4080,17 +4080,18 @@ ieee80211_sta_scan_result(struct net_device *dev,
IW_EV_UINT_LEN);
}

+
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
- iwe.u.freq.m = bss->freq;
- iwe.u.freq.e = 6;
+ iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
+ iwe.u.freq.e = 0;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);

memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
- iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
- iwe.u.freq.e = 0;
+ iwe.u.freq.m = bss->freq;
+ iwe.u.freq.e = 6;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);

Tomas

2008-05-11 02:49:58

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sun, 2008-05-11 at 01:06 +0300, Tomas Winkler wrote:
> On Sun, May 11, 2008 at 12:48 AM, Vincent C Jones
> <[email protected]> wrote:
> >
> > On Sat, 2008-05-10 at 21:56 +0300, Tomas Winkler wrote:
> >> >
> >> > May be more to this than just missing 802.11a channel reporting...
> >> > walked to within range of a NetGear dual-band 802.11N 5GHz/11G 2.4GHz AP
> >> > and could not even see the 802.11A side of the AP, (while another
> >> > machine was associated with it, so both halves of the AP were up).
> >> > I associated on the G channel, then tried to force an association on the
> >> > A channel by setting the frequency with iwconfig. At some point, I got
> >> > the following (note that I could still associate with the G channel when
> >> > done):
> >> >
> >> > ay 10 11:20:04 X61 kernel: ------------[ cut here ]------------
> >> > May 10 11:20:04 X61 kernel: WARNING: at
> >> > include/../net/mac80211/rate.h:153 rs_get_rate+0x159/0x194 [iwl4965]()
> >>
> >> Something went wrong with station management. Do you use same BSSID
> >> on the both interfaces A and G?
> >>
> >> Thanks
> >> Tomas
> >
> > No.
> > 1st Floor-NetGear Dual Band AGN A/N on 36, BSSID = NetworkingUnlimited
> > G on 11, BSSID = NetworkingUnlimited-G
> > 2nd Floor - 3Com POE A/G in A modeA on 48, BSSID = NetworkingUnlimited
> >
>
> I'm asking for BSSID like mac address not SSID like network name
> Thanks
> Tomas

Oops, my bad... According to iwlist scan under 2.6.25, the BSSIDs are
unique:

Cell 04 - Address: 00:1E:2A:6C:93:D9
ESSID:"NetworkingUnlimited-G"
Mode:Master
Channel:11
Frequency:2.462 GHz (Channel 11)
Quality=93/100 Signal level=-36 dBm Noise
level=-127 dBm
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
12 Mb/s; 48 Mb/s
Extra:tsf=00000004af8444ec
Cell 05 - Address: 00:1E:2A:6C:93:D8
ESSID:"NetworkingUnlimited"
Mode:Master
Channel:36
Frequency:5.18 GHz (Channel 36)
Quality=79/100 Signal level=-55 dBm Noise
level=-127 dBm
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Extra:tsf=00000004af3660e3

2008-05-22 18:34:29

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 19:56 +0200, Johannes Berg wrote:
> > memset(&iwe, 0, sizeof(iwe));
> > iwe.cmd = SIOCGIWFREQ;
> > - iwe.u.freq.m = bss->freq;
> > - iwe.u.freq.e = 6;
> > + iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> > + iwe.u.freq.e = 0;
> > current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> > IW_EV_FREQ_LEN);
> >
> > memset(&iwe, 0, sizeof(iwe));
> > iwe.cmd = SIOCGIWFREQ;
> > - iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> > - iwe.u.freq.e = 0;
> > + iwe.u.freq.m = bss->freq;
> > + iwe.u.freq.e = 6;
> > current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> > IW_EV_FREQ_LEN);
>
> That doesn't make any sense, can you explain?

Explanation:

wpa_supplicant cannot handle A-band channel #s. Thus, with the previous
code, the FREQ+frequency was sent first, and the FREQ+channel was sent
second. Sending the FREQ+channel second made the supplicant overwrite
the value it already parsed from the FREQ+frequency for that BSSID. But
since the supplicant can't handle A-band channel #s, you end up with 0.

Reversing the order of these two makes it work, but it's a total hack.
That may be what's needed right now though until everyone fixes their
supplicant. There's overlap on A-band channels 7 - 12 (5035MHz ->
5060MHz) with B/G band channel #s. Obviously WEXT falls over here
because the band isn't passed.

But what's the best fix to the supplicant? It could just parse A-band
channels and where the numbers overlap, assume B/G band. Or, it could
be patched to prefer FREQ+frequency over FREQ+channel if it received
both. That's probably the best solution.

Dan

2008-05-22 23:28:25

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> >
> > Applied patch to today's
> > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> > and I can confirm that wpa_supplicant v0.6.3 again works on the A band.
> >
> > FWIW, however, I still have some issues:
> >
> > 1 - Roaming from 3com to NetGear takes about 5 minutes before iwlist
> > scan sees the A/N channel on the NetGear AP. Roaming from NetGear to
> > 3com, however, the 3com AP is seen on the first scan after losing
> > contact.
>
> What channel is NG?, what is the beacon period.

Primary is 36, secondary is 40. (3com is 48). Beacon period is not a
settable parameter on the Netgear and is not documented (3com is set to
default 100ms).

> We'll soon release a new uCode that should speed up a bit scanning on A band.

That would be nice, we need several orders of magnitude improvement
here...

> > 2 - The NetGear is allegedly 11n, but shows up as standard A (or G) in
> > iwconfig et al. Highest data rate listed by iwlist is 54 on A, 48 on G.
>
> wext doesn't report 11n rates and probably never will, it doesn't mean
> there is no 11n connection.

When I have nothing better to do I'll have to try some performance
testing :-)

> Currently I don't have some non crypto interface looking into it.
>
> > 3 - Booting Windows, the 4965 does see the NetGear as 802.11n, so I
> > can't blame it on the hardware...
> >
> No you cant :)
>
> > 4 - I won't guarantee it is not a configuration issue on my part...
> > attached is the ".config" file used to compile the kernel.
> >
> Looks good.
>
> Tomas

Thanks, I appreciate all your good work and support.

Vince

2008-05-22 22:50:16

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Fri, May 23, 2008 at 1:33 AM, Vincent C Jones
<[email protected]> wrote:
> On Thu, 2008-05-22 at 19:53 +0300, Tomas Winkler wrote:
>> On Mon, May 12, 2008 at 9:37 PM, Vincent C Jones
>> <[email protected]> wrote:
>> >
>> > On Mon, 2008-05-12 at 19:50 +0300, Tomas Winkler wrote:
>> >
>> >> Meanwhile we've reproduced the wpa_supplicant issue...
>> >>
>> >
>> > That is great news. Let me know when it is time to test again...
>>
>> Please try this one. I've just pasted that in so it's might be
>> white-space-wise broken
>>
>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> index 7877d3b..5996e3d 100644
>> * * *
>> Tomas
>
> Tomas,
>
> Applied patch to today's
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> and I can confirm that wpa_supplicant v0.6.3 again works on the A band.
>
> FWIW, however, I still have some issues:
>
> 1 - Roaming from 3com to NetGear takes about 5 minutes before iwlist
> scan sees the A/N channel on the NetGear AP. Roaming from NetGear to
> 3com, however, the 3com AP is seen on the first scan after losing
> contact.

What channel is NG?, what is the beacon period.
We'll soon release a new uCode that should speed up a bit scanning on A band.

> 2 - The NetGear is allegedly 11n, but shows up as standard A (or G) in
> iwconfig et al. Highest data rate listed by iwlist is 54 on A, 48 on G.

wext doesn't report 11n rates and probably never will, it doesn't mean
there is no 11n connection.
Currently I don't have some non crypto interface looking into it.

> 3 - Booting Windows, the 4965 does see the NetGear as 802.11n, so I
> can't blame it on the hardware...
>
No you cant :)

> 4 - I won't guarantee it is not a configuration issue on my part...
> attached is the ".config" file used to compile the kernel.
>
Looks good.

Tomas

2008-05-12 18:48:49

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Mon, 2008-05-12 at 19:50 +0300, Tomas Winkler wrote:

> Meanwhile we've reproduced the wpa_supplicant issue...
>

That is great news. Let me know when it is time to test again...

Vince

2008-05-10 14:12:40

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

2008-05-22 22:07:42

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 23:56 +0300, Tomas Winkler wrote:
> On Thu, May 22, 2008 at 10:34 PM, Johannes Berg
> <[email protected]> wrote:
> >
> >> > Fun. How about it we just make wpa supplicant ignore FREQ/channel
> >> > completely if it uses FREQ/frequency anyway?
> >>
> >> Can't because some drivers send channel and not frequency. Yeah, we
> >> could fix all the drivers, but that doesn't help people running latest
> >> supplicant on older kernels.
> >
> > Oh, good point. I guess the patch you posted is the only sane thing to
> > do then, and require that drivers that work in the 5 GHz band send
> > frequency (because there channel numbers need not be unique due to
> > 802.11j's channelisation offset)
> >
>
> Fix in the mac should go in as well in so it will work with older
> supplicants and it doesn't really hurt.

Yup. Both parts (mac80211 FREQ re-order, and supplicant patch) should
be applied.

Dan

2008-05-22 21:10:57

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> Fix in the mac should go in as well in so it will work with older
> supplicants and it doesn't really hurt.

Yeah sure.

johannes

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2008-05-22 19:17:36

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> > memset(&iwe, 0, sizeof(iwe));
> > iwe.cmd = SIOCGIWFREQ;
> > - iwe.u.freq.m = bss->freq;
> > - iwe.u.freq.e = 6;
> > + iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> > + iwe.u.freq.e = 0;
> > current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> > IW_EV_FREQ_LEN);
> >
> > memset(&iwe, 0, sizeof(iwe));
> > iwe.cmd = SIOCGIWFREQ;
> > - iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> > - iwe.u.freq.e = 0;
> > + iwe.u.freq.m = bss->freq;
> > + iwe.u.freq.e = 6;
> > current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> > IW_EV_FREQ_LEN);
>
> Wait a minute; what's mac80211 sending _two_ FREQ events for? That's
> not right.

Why not? It has always done that, different units, one with channel and
one with freq, iwlist will show both which is very useful.

johannes

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2008-05-22 18:50:05

by Pavel Roskin

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 14:34 -0400, Dan Williams wrote:

> But what's the best fix to the supplicant? It could just parse A-band
> channels and where the numbers overlap, assume B/G band. Or, it could
> be patched to prefer FREQ+frequency over FREQ+channel if it received
> both. That's probably the best solution.

I checked the wpa_supplicant sources and I see that all it needs is the
frequency. All that needs to be done is not to allow channels
(everything below, say, 10000) overwrite existing frequency data.
That's the second approach.

--
Regards,
Pavel Roskin

2008-05-22 18:22:53

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 19:53 +0300, Tomas Winkler wrote:
> On Mon, May 12, 2008 at 9:37 PM, Vincent C Jones
> <[email protected]> wrote:
> >
> > On Mon, 2008-05-12 at 19:50 +0300, Tomas Winkler wrote:
> >
> >> Meanwhile we've reproduced the wpa_supplicant issue...
> >>
> >
> > That is great news. Let me know when it is time to test again...
>
> Please try this one. I've just pasted that in so it's might be
> white-space-wise broken
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 7877d3b..5996e3d 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -4080,17 +4080,18 @@ ieee80211_sta_scan_result(struct net_device *dev,
> IW_EV_UINT_LEN);
> }
>
> +
> memset(&iwe, 0, sizeof(iwe));
> iwe.cmd = SIOCGIWFREQ;
> - iwe.u.freq.m = bss->freq;
> - iwe.u.freq.e = 6;
> + iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> + iwe.u.freq.e = 0;
> current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> IW_EV_FREQ_LEN);
>
> memset(&iwe, 0, sizeof(iwe));
> iwe.cmd = SIOCGIWFREQ;
> - iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> - iwe.u.freq.e = 0;
> + iwe.u.freq.m = bss->freq;
> + iwe.u.freq.e = 6;
> current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> IW_EV_FREQ_LEN);

Wait a minute; what's mac80211 sending _two_ FREQ events for? That's
not right.

Dan

2008-05-09 21:23:16

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Fri, May 9, 2008 at 7:57 PM, Vincent C Jones
<[email protected]> wrote:
> The channel/frequency reporting by iwlwifi is incompatible with
> wpa_supplicant for 5GHz (802.11A) channels. Version numbers and iwlist
> versus wpa_supplicant scan results are below. Association still works if
> the correct channel is specified using iwconfig, but that is
> incompatible with roaming.

Fixed by the patch ' iwlwifi: Fix frequency in rx_status fill'

Thanks
Tomas

2008-05-22 19:18:46

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, 2008-05-22 at 14:50 -0400, Pavel Roskin wrote:
> On Thu, 2008-05-22 at 14:34 -0400, Dan Williams wrote:
>
> > But what's the best fix to the supplicant? It could just parse A-band
> > channels and where the numbers overlap, assume B/G band. Or, it could
> > be patched to prefer FREQ+frequency over FREQ+channel if it received
> > both. That's probably the best solution.
>
> I checked the wpa_supplicant sources and I see that all it needs is the
> frequency. All that needs to be done is not to allow channels
> (everything below, say, 10000) overwrite existing frequency data.
> That's the second approach.

works for me. something like the following? will repost to hostap list
if this looks ok.

diff --git a/src/drivers/driver_wext.c b/src/drivers/driver_wext.c
index 69aae16..60cdb79 100644
--- a/src/drivers/driver_wext.c
+++ b/src/drivers/driver_wext.c
@@ -1294,8 +1294,15 @@ static void wext_get_scan_freq(struct iw_event *iwe,
/*
* Some drivers do not report frequency, but a channel.
* Try to map this to frequency by assuming they are using
- * IEEE 802.11b/g.
+ * IEEE 802.11b/g. But don't overwrite a previously parsed
+ * frequency if the driver sends both frequency and channel,
+ * since the driver may be sending an A-band channel that we
+ * don't handle here.
*/
+
+ if (res->res.freq)
+ return;
+
if (iwe->u.freq.m >= 1 && iwe->u.freq.m <= 13) {
res->res.freq = 2407 + 5 * iwe->u.freq.m;
return;

I guess the better solution would be to handle A-band channels too. Is
there a canonical mapping of channel # to frequency somewhere for the
A-band stuff? I put together the following table a while ago from
googling around which is probably the wrong way to do it, but... my
sources were mainly wikipedia channel maps for 802.11a and some cisco
docs from somewhere.

Dan

static struct cf_pair a_table[] = {
/* A band */
{ 7, 5035 },
{ 8, 5040 },
{ 9, 5045 },
{ 11, 5055 },
{ 12, 5060 },
{ 16, 5080 },
{ 34, 5170 },
{ 36, 5180 },
{ 38, 5190 },
{ 40, 5200 },
{ 42, 5210 },
{ 44, 5220 },
{ 46, 5230 },
{ 48, 5240 },
{ 50, 5250 },
{ 52, 5260 },
{ 56, 5280 },
{ 58, 5290 },
{ 60, 5300 },
{ 64, 5320 },
{ 100, 5500 },
{ 104, 5520 },
{ 108, 5540 },
{ 112, 5560 },
{ 116, 5580 },
{ 120, 5600 },
{ 124, 5620 },
{ 128, 5640 },
{ 132, 5660 },
{ 136, 5680 },
{ 140, 5700 },
{ 149, 5745 },
{ 152, 5760 },
{ 153, 5765 },
{ 157, 5785 },
{ 160, 5800 },
{ 161, 5805 },
{ 165, 5825 },
{ 183, 4915 },
{ 184, 4920 },
{ 185, 4925 },
{ 187, 4935 },
{ 188, 4945 },
{ 192, 4960 },
{ 196, 4980 },
{ 0, -1 }
};

2008-05-22 18:51:56

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, May 22, 2008 at 9:34 PM, Dan Williams <[email protected]> wrote:
> On Thu, 2008-05-22 at 19:56 +0200, Johannes Berg wrote:
>> > memset(&iwe, 0, sizeof(iwe));
>> > iwe.cmd = SIOCGIWFREQ;
>> > - iwe.u.freq.m = bss->freq;
>> > - iwe.u.freq.e = 6;
>> > + iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
>> > + iwe.u.freq.e = 0;
>> > current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
>> > IW_EV_FREQ_LEN);
>> >
>> > memset(&iwe, 0, sizeof(iwe));
>> > iwe.cmd = SIOCGIWFREQ;
>> > - iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
>> > - iwe.u.freq.e = 0;
>> > + iwe.u.freq.m = bss->freq;
>> > + iwe.u.freq.e = 6;
>> > current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
>> > IW_EV_FREQ_LEN);
>>
>> That doesn't make any sense, can you explain?
>
> Explanation:
>
> wpa_supplicant cannot handle A-band channel #s. Thus, with the previous
> code, the FREQ+frequency was sent first, and the FREQ+channel was sent
> second. Sending the FREQ+channel second made the supplicant overwrite
> the value it already parsed from the FREQ+frequency for that BSSID. But
> since the supplicant can't handle A-band channel #s, you end up with 0.
>
> Reversing the order of these two makes it work, but it's a total hack.
> That may be what's needed right now though until everyone fixes their
> supplicant. There's overlap on A-band channels 7 - 12 (5035MHz ->
> 5060MHz) with B/G band channel #s. Obviously WEXT falls over here
> because the band isn't passed.
>
> But what's the best fix to the supplicant? It could just parse A-band
> channels and where the numbers overlap, assume B/G band. Or, it could
> be patched to prefer FREQ+frequency over FREQ+channel if it received
> both. That's probably the best solution.
>
Thanks for clearing this fog.

Actually we've also tried to removing FREQ+channel part and it has
worked. So wpa_supplicant won't get into this dilemma. Although I have
never seen anyone used 7-12 channels in 5.2 band.
My patch just restored the code that was present before it has broken.
>From what you wrote it looks like the problem is rather in wext then
in wpa_supplicant.

I will sent and official patch if some more people confirms it solves
their problem.

Patch that broke it is below so I guess the bug is in everything form
2.6.25 and up.
'
commit 8318d78a44d49ac1edf2bdec7299de3617c4232e
Author: Johannes Berg <[email protected]>
Date: Thu Jan 24 19:38:38 2008 +0100

cfg80211 API for channels/bitrates, mac80211 and driver conversion
'

Tomas

2008-05-22 17:58:55

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Thu, May 22, 2008 at 8:56 PM, Johannes Berg
<[email protected]> wrote:
>
>> memset(&iwe, 0, sizeof(iwe));
>> iwe.cmd = SIOCGIWFREQ;
>> - iwe.u.freq.m = bss->freq;
>> - iwe.u.freq.e = 6;
>> + iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
>> + iwe.u.freq.e = 0;
>> current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
>> IW_EV_FREQ_LEN);
>>
>> memset(&iwe, 0, sizeof(iwe));
>> iwe.cmd = SIOCGIWFREQ;
>> - iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
>> - iwe.u.freq.e = 0;
>> + iwe.u.freq.m = bss->freq;
>> + iwe.u.freq.e = 6;
>> current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
>> IW_EV_FREQ_LEN);
>
> That doesn't make any sense, can you explain?
>
Your patch switched order of channel and freq in the scan
It looks like wpa_supplicant cannot handle it

Tomas

2008-05-22 17:57:15

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

> memset(&iwe, 0, sizeof(iwe));
> iwe.cmd = SIOCGIWFREQ;
> - iwe.u.freq.m = bss->freq;
> - iwe.u.freq.e = 6;
> + iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> + iwe.u.freq.e = 0;
> current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> IW_EV_FREQ_LEN);
>
> memset(&iwe, 0, sizeof(iwe));
> iwe.cmd = SIOCGIWFREQ;
> - iwe.u.freq.m = ieee80211_frequency_to_channel(bss->freq);
> - iwe.u.freq.e = 0;
> + iwe.u.freq.m = bss->freq;
> + iwe.u.freq.e = 6;
> current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
> IW_EV_FREQ_LEN);

That doesn't make any sense, can you explain?

johannes

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2008-05-10 22:06:53

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sun, May 11, 2008 at 12:48 AM, Vincent C Jones
<[email protected]> wrote:
>
> On Sat, 2008-05-10 at 21:56 +0300, Tomas Winkler wrote:
>> >
>> > May be more to this than just missing 802.11a channel reporting...
>> > walked to within range of a NetGear dual-band 802.11N 5GHz/11G 2.4GHz AP
>> > and could not even see the 802.11A side of the AP, (while another
>> > machine was associated with it, so both halves of the AP were up).
>> > I associated on the G channel, then tried to force an association on the
>> > A channel by setting the frequency with iwconfig. At some point, I got
>> > the following (note that I could still associate with the G channel when
>> > done):
>> >
>> > ay 10 11:20:04 X61 kernel: ------------[ cut here ]------------
>> > May 10 11:20:04 X61 kernel: WARNING: at
>> > include/../net/mac80211/rate.h:153 rs_get_rate+0x159/0x194 [iwl4965]()
>>
>> Something went wrong with station management. Do you use same BSSID
>> on the both interfaces A and G?
>>
>> Thanks
>> Tomas
>
> No.
> 1st Floor-NetGear Dual Band AGN A/N on 36, BSSID = NetworkingUnlimited
> G on 11, BSSID = NetworkingUnlimited-G
> 2nd Floor - 3Com POE A/G in A modeA on 48, BSSID = NetworkingUnlimited
>

I'm asking for BSSID like mac address not SSID like network name
Thanks
Tomas
>

2008-05-10 15:46:45

[permalink] [raw]

Subject: Re: iwl4965 - wpa_supplicant can't see 5Ghz frequencies - 2.6.26-rc1 kernel

On Sat, 2008-05-10 at 10:39 -0400, Vincent C Jones wrote:
> On Sat, 2008-05-10 at 03:12 +0300, Tomas Winkler wrote:
> > On Sat, May 10, 2008 at 2:41 AM, Vincent C Jones
> > <[email protected]> wrote:
> > >
> > > On Sat, 2008-05-10 at 00:23 +0300, Tomas Winkler wrote:
> > >> On Fri, May 9, 2008 at 7:57 PM, Vincent C Jones
> > >> <[email protected]> wrote:
> > >> > The channel/frequency reporting by iwlwifi is incompatible with
> > >> > wpa_supplicant for 5GHz (802.11A) channels. Version numbers and iwlist
> > >> > versus wpa_supplicant scan results are below. Association still works if
> > >> > the correct channel is specified using iwconfig, but that is
> > >> > incompatible with roaming.
> > >>
> > >> Fixed by the patch ' iwlwifi: Fix frequency in rx_status fill'
> > >>
> > >> Thanks
> > >> Tomas
> > >
> > > This patch did not apply cleanly to plain 2.6.26-rc1: off by -4 lines in
> > > iwl-3945.c and by 1078 lines in iwl-4965.c. More important, it did not
> > > fix the problem of wpa_supplicant thinking the 802.11A access points are
> > > on channel 0. Same results with 2.6.26-rc1-git7, with & without patch.
> > > Any idea when this patch (and the patches it appears to depend on) will
> > > make it into the 2.6.26 release?
> > >
> >
> > This patch is against wireless-testing.git, it's just too lines and
> > doesn't really have logical dependencies on other patches so I didn't
> > create a separate patch for 2.6.26...It looks maybe I should.
> > Can you try to eproduce your problem on wireless-testing kernel with
> > this patch?
> > Also some logs will be useful
> >
> > Thanks
> > Tomas
>
> Tomas,
>
> No joy. Did I git the wrong tree?
>
> (git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git)
>
> Still had to apply your patch (offset 223 lines this time). Also applied
> the media/built-in.o patch so my config would compile. Wpa_supplicant
> (v0.6.3) still reports 0 for the channel of 11A stations:

May be more to this than just missing 802.11a channel reporting...
walked to within range of a NetGear dual-band 802.11N 5GHz/11G 2.4GHz AP
and could not even see the 802.11A side of the AP, (while another
machine was associated with it, so both halves of the AP were up).
I associated on the G channel, then tried to force an association on the
A channel by setting the frequency with iwconfig. At some point, I got
the following (note that I could still associate with the G channel when
done):

ay 10 11:20:04 X61 kernel: ------------[ cut here ]------------
May 10 11:20:04 X61 kernel: WARNING: at
include/../net/mac80211/rate.h:153 rs_get_rate+0x159/0x194 [iwl4965]()
May 10 11:20:04 X61 kernel: Modules linked in: iwl4965 iwlcore rfkill
mac80211 cfg80211 aes_x86_64 aes_generic rfcomm iptable_filter ip_tables
ip6_tables x_tables i915 drm af_packet cpufreq_conservative
cpufreq_userspace l2cap cpufreq_powersave acpi_cpufreq snd_pcm_oss
snd_mixer_oss snd_seq snd_seq_device microcode ext3 jbd mbcache fuse
nls_iso8859_1 nls_cp437 vfat fat loop dm_mod tp_smapi thinkpad_ec
input_polldev pata_acpi ata_generic ata_piix arc4 ecb crypto_blkcipher
ide_pci_generic thinkpad_acpi mmc_block piix bay pcmcia firmware_class
hci_usb output battery intel_agp ac e1000e ide_core snd_hda_intel
snd_pcm snd_timer snd_page_alloc rtc_cmos snd_hwdep rtc_core rtc_lib snd
led_class sdhci mmc_core button bluetooth yenta_socket ohci1394
rsrc_nonstatic i2c_i801 i2c_core soundcore ieee1394 pcmcia_core sg
uinput sd_mod ehci_hcd uhci_hcd usbcore edd reiserfs fan ahci libata
scsi_mod dock thermal processor thermal_sys hwmon [last unloaded:
cfg80211]
May 10 11:20:04 X61 kernel: Pid: 4947, comm: iwl4965 Not tainted
2.6.26-rc1-wl-test #2
May 10 11:20:04 X61 kernel:
May 10 11:20:04 X61 kernel: Call Trace:
May 10 11:20:04 X61 kernel: [<ffffffff8022dbb5>] warn_on_slowpath
+0x51/0x79
May 10 11:20:04 X61 kernel:
[<ffffffffa029b5fc>] :mac80211:ieee80211_rx_bss_info+0x829/0x83b
May 10 11:20:04 X61 kernel:
[<ffffffffa029b783>] :mac80211:ieee80211_rx_mgmt_beacon+0x175/0x185
May 10 11:20:04 X61 kernel: [<ffffffffa02d4bc1>] :iwl4965:rs_get_rate
+0x159/0x194
May 10 11:20:04 X61 kernel: [<ffffffff802837a9>] cache_alloc_refill
+0x89/0x481
May 10 11:20:04 X61 kernel:
[<ffffffffa029feaf>] :mac80211:rate_control_get_rate+0x79/0xdd
May 10 11:20:04 X61 kernel:
[<ffffffffa02a46d9>] :mac80211:ieee80211_tx_h_rate_ctrl+0x31/0xfa
May 10 11:20:04 X61 kernel:
[<ffffffffa02a546c>] :mac80211:ieee80211_master_start_xmit+0x1ea/0x370
May 10 11:20:04 X61 kernel: [<ffffffff803a7f43>] __qdisc_run+0xbc/0x1af
May 10 11:20:04 X61 kernel: [<ffffffff8039ab63>] dev_queue_xmit
+0x153/0x264
May 10 11:20:04 X61 kernel:
[<ffffffffa029ccf8>] :mac80211:ieee80211_associated+0xe7/0x189
May 10 11:20:04 X61 kernel:
[<ffffffffa029ef61>] :mac80211:ieee80211_sta_work+0x0/0x733
May 10 11:20:04 X61 kernel:
[<ffffffffa029f468>] :mac80211:ieee80211_sta_work+0x507/0x733
May 10 11:20:04 X61 kernel: [<ffffffff80228abb>] hrtick_set+0x88/0xf6
May 10 11:20:04 X61 kernel: [<ffffffff80401ddc>] thread_return
+0x68/0xac
May 10 11:20:04 X61 kernel:
[<ffffffffa029ef61>] :mac80211:ieee80211_sta_work+0x0/0x733
May 10 11:20:04 X61 kernel: [<ffffffff8023c09c>] run_workqueue
+0x79/0x104
May 10 11:20:04 X61 kernel: [<ffffffff8023c975>] worker_thread
+0xd9/0xe8
May 10 11:20:04 X61 kernel: [<ffffffff8023f19c>]
autoremove_wake_function+0x0/0x2e
May 10 11:20:04 X61 kernel: [<ffffffff8023c89c>] worker_thread+0x0/0xe8
May 10 11:20:04 X61 kernel: [<ffffffff8023f080>] kthread+0x47/0x73
May 10 11:20:04 X61 kernel: [<ffffffff80228cd2>] schedule_tail
+0x28/0x5d
May 10 11:20:04 X61 kernel: [<ffffffff8020cbd8>] child_rip+0xa/0x12
May 10 11:20:04 X61 kernel: [<ffffffff8023f039>] kthread+0x0/0x73
May 10 11:20:04 X61 kernel: [<ffffffff8020cbce>] child_rip+0x0/0x12
May 10 11:20:04 X61 kernel:
May 10 11:20:04 X61 kernel: ---[ end trace b453f118a4b6c339 ]---
May 10 11:20:06 X61 kernel: wlan0: No ProbeResp from current AP
00:1e:2a:6c:93:d9 - assume out of range
May 10 11:20:06 X61 kernel: wlan0: Initial auth_alg=0
May 10 11:20:06 X61 kernel: wlan0: authenticate with AP
00:1e:2a:6c:93:d9
May 10 11:20:06 X61 kernel: wlan0: Initial auth_alg=0
May 10 11:20:06 X61 kernel: wlan0: authenticate with AP
00:1e:2a:6c:93:d9
May 10 11:20:06 X61 kernel: wlan0: RX authentication from
00:1e:2a:6c:93:d9 (alg=0 transaction=2 status=0)
May 10 11:20:06 X61 kernel: wlan0: authenticated
May 10 11:20:06 X61 kernel: wlan0: associate with AP 00:1e:2a:6c:93:d9
May 10 11:20:06 X61 kernel: wlan0: authentication frame received from
00:1e:2a:6c:93:d9, but not in authenticate state - ignored
May 10 11:20:06 X61 kernel: wlan0: RX ReassocResp from 00:1e:2a:6c:93:d9
(capab=0x411 status=0 aid=1)
May 10 11:20:06 X61 kernel: wlan0: associated
May 10 11:20:06 X61 kernel: wlan0: switched to short barker preamble
(BSSID=00:1e:2a:6c:93:d9)

###
Vince

2008-05-12 16:50:31