Hello,
my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
the 5GHz band between 3.3 and 3.4-rc2.
After 14 git bisects, I believe I have narrowed it down to the following patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
mac80211: use common radiotap code for cooked monitors
Prior to this change, everything works. After this change, an Intel
Corporation Centrino Advanced-N 6205 is able to see the AP using
"iwlist wlan0 scan", but the following shows up in dmesg when trying
to associate (on the intel side):
[ 7636.834579] wlan0: direct probe to 90:f6:52:0d:0a:5e timed out
[ 7644.201671] wlan0: direct probe to 90:f6:52:0d:0a:5e (try 1/3)
[ 7644.400767] wlan0: direct probe to 90:f6:52:0d:0a:5e (try 2/3)
[ 7644.600323] wlan0: direct probe to 90:f6:52:0d:0a:5e (try 3/3)
-Andrew
Felix Fietkau wrote:
> On 2012-04-24 2:54 PM, John W. Linville wrote:
>> On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
>>> Andrew Chant wrote:
>>>> 3.4-rc4 doesn't work either.
>>>> If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
>>>> -Andrew
>>>>
>>>> On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>>>>> Hello,
>>>>> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>>>>> the 5GHz band between 3.3 and 3.4-rc2.
>>>>> After 14 git bisects, I believe I have narrowed it down to the following patch:
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>>>>>
>>>>> mac80211: use common radiotap code for cooked monitors
>>>
>>> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
>>> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>>>
>>> Removing "mac80211: use common radiotap code for cooked monitors" solves
>>> the problem here, too.
>>>
>>> Using rt2860 as AP seems not to be a problem.
>>
>> Sounds like we may need to revert it upstream. Johannes, any comments?
> That's a known bug, which I submitted a fix for. When looking at the
> 3.4-rc4 log, I don't see my fix in there. It was submitted as
> "[PATCH] mac80211: fix truncated packets in cooked monitor rx"
This patch fixes the problem here with ar9285 / AP.
Kind regards,
Andreas
On 2012-04-24 2:54 PM, John W. Linville wrote:
> On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
>> Andrew Chant wrote:
>> > 3.4-rc4 doesn't work either.
>> > If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
>> > -Andrew
>> >
>> > On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>> >> Hello,
>> >> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>> >> the 5GHz band between 3.3 and 3.4-rc2.
>> >> After 14 git bisects, I believe I have narrowed it down to the following patch:
>> >>
>> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>> >>
>> >> mac80211: use common radiotap code for cooked monitors
>>
>> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
>> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>>
>> Removing "mac80211: use common radiotap code for cooked monitors" solves
>> the problem here, too.
>>
>> Using rt2860 as AP seems not to be a problem.
>
> Sounds like we may need to revert it upstream. Johannes, any comments?
That's a known bug, which I submitted a fix for. When looking at the
3.4-rc4 log, I don't see my fix in there. It was submitted as
"[PATCH] mac80211: fix truncated packets in cooked monitor rx"
- Felix
On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
> Andrew Chant wrote:
> > 3.4-rc4 doesn't work either.
> > If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
> > -Andrew
> >
> > On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
> >> Hello,
> >> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
> >> the 5GHz band between 3.3 and 3.4-rc2.
> >> After 14 git bisects, I believe I have narrowed it down to the following patch:
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
> >>
> >> mac80211: use common radiotap code for cooked monitors
>
> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>
> Removing "mac80211: use common radiotap code for cooked monitors" solves
> the problem here, too.
>
> Using rt2860 as AP seems not to be a problem.
Sounds like we may need to revert it upstream. Johannes, any comments?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
3.4-rc4 doesn't work either.
If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
-Andrew
On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
> Hello,
> ?my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
> the 5GHz band between 3.3 and 3.4-rc2.
> After 14 git bisects, I believe I have narrowed it down to the following patch:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>
> mac80211: use common radiotap code for cooked monitors
>
> Prior to this change, everything works. ?After this change, an Intel
> Corporation Centrino Advanced-N 6205 is able to see the AP using
> "iwlist wlan0 scan", but the following shows up in dmesg when trying
> to associate (on the intel side):
>
> [ 7636.834579] wlan0: direct probe to 90:f6:52:0d:0a:5e timed out
> [ 7644.201671] wlan0: direct probe to 90:f6:52:0d:0a:5e (try 1/3)
> [ 7644.400767] wlan0: direct probe to 90:f6:52:0d:0a:5e (try 2/3)
> [ 7644.600323] wlan0: direct probe to 90:f6:52:0d:0a:5e (try 3/3)
>
> -Andrew
On Apr 25, 2012, at 10:42 AM, Felix Fietkau wrote:
> On 2012-04-24 2:54 PM, John W. Linville wrote:
>> On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
>>> Andrew Chant wrote:
>>>> 3.4-rc4 doesn't work either.
>>>> If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
>>>> -Andrew
>>>>
>>>> On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>>>>> Hello,
>>>>> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>>>>> the 5GHz band between 3.3 and 3.4-rc2.
>>>>> After 14 git bisects, I believe I have narrowed it down to the following patch:
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>>>>>
>>>>> mac80211: use common radiotap code for cooked monitors
>>>
>>> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
>>> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>>>
>>> Removing "mac80211: use common radiotap code for cooked monitors" solves
>>> the problem here, too.
>>>
>>> Using rt2860 as AP seems not to be a problem.
>>
>> Sounds like we may need to revert it upstream. Johannes, any comments?
> That's a known bug, which I submitted a fix for. When looking at the
> 3.4-rc4 log, I don't see my fix in there. It was submitted as
> "[PATCH] mac80211: fix truncated packets in cooked monitor rx"
Just as another data-point, I'm using ath9k for an AR9300 Rev:3 chipset
with compat-wireless-v3.4-rc3-1, and it doesn't work as an AP in any case:
Stock code:
fails
Reverting [PATCH] mac80211: use common radiotap code for cooked monitors:
fails
Leaving the above in place and applying Felix's radiotap patch:
fails
I get a lot of these logs from hostapd:
1335397090.413064: Could not parse ProbeReq from 00:24:44:f5:e3:c2
I'm using hostapd 0.7.3. If I rewind to an earlier "stable", it works -
at least the AP works; there is a bug in client mode when connecting to
a WEP AP, which is fixed in v3.4-rc3-1.
Should I try switching from "stable" to "next"?
--
-bp
Andrew Chant wrote:
> 3.4-rc4 doesn't work either.
> If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
> -Andrew
>
> On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>> Hello,
>> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>> the 5GHz band between 3.3 and 3.4-rc2.
>> After 14 git bisects, I believe I have narrowed it down to the following patch:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>>
>> mac80211: use common radiotap code for cooked monitors
Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
Removing "mac80211: use common radiotap code for cooked monitors" solves
the problem here, too.
Using rt2860 as AP seems not to be a problem.
Regards,
Andreas Hartmann
Felix's patch directly applied on top of 3.4.0-rc4 works in my case.
-Andrew
On Wed, Apr 25, 2012 at 10:42 AM, Felix Fietkau <[email protected]> wrote:
> On 2012-04-24 2:54 PM, John W. Linville wrote:
>> On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
>>> Andrew Chant wrote:
>>> > 3.4-rc4 doesn't work either.
>>> > If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
>>> > -Andrew
>>> >
>>> > On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>>> >> Hello,
>>> >> ?my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>>> >> the 5GHz band between 3.3 and 3.4-rc2.
>>> >> After 14 git bisects, I believe I have narrowed it down to the following patch:
>>> >>
>>> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>>> >>
>>> >> mac80211: use common radiotap code for cooked monitors
>>>
>>> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
>>> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>>>
>>> Removing "mac80211: use common radiotap code for cooked monitors" solves
>>> the problem here, too.
>>>
>>> Using rt2860 as AP seems not to be a problem.
>>
>> Sounds like we may need to revert it upstream. ?Johannes, any comments?
> That's a known bug, which I submitted a fix for. When looking at the
> 3.4-rc4 log, I don't see my fix in there. It was submitted as
> "[PATCH] mac80211: fix truncated packets in cooked monitor rx"
>
> - Felix
Felix Fietkau wrote:
> On 2012-04-24 2:54 PM, John W. Linville wrote:
>> On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
>>> Andrew Chant wrote:
>>>> 3.4-rc4 doesn't work either.
>>>> If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
>>>> -Andrew
>>>>
>>>> On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>>>>> Hello,
>>>>> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>>>>> the 5GHz band between 3.3 and 3.4-rc2.
>>>>> After 14 git bisects, I believe I have narrowed it down to the following patch:
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>>>>>
>>>>> mac80211: use common radiotap code for cooked monitors
>>>
>>> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
>>> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>>>
>>> Removing "mac80211: use common radiotap code for cooked monitors" solves
>>> the problem here, too.
>>>
>>> Using rt2860 as AP seems not to be a problem.
>>
>> Sounds like we may need to revert it upstream. Johannes, any comments?
> That's a known bug, which I submitted a fix for. When looking at the
> 3.4-rc4 log, I don't see my fix in there. It was submitted as
> "[PATCH] mac80211: fix truncated packets in cooked monitor rx"
Well, there is another patch missing, too:
"[PATCH] rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
This patch should be applied, too, in order to get APs with Ralink PCI
chipsets working again.
Thank you,
kind regards,
Andreas
It seems like 3.4-rc3-1 is still the latest package available for download on the website, even though
it's not usable as an AP. Is there an ETA for an update that works as an AP?
Thanks,
--
-bp
On Apr 25, 2012, at 4:46 PM, Bryan Phillippe wrote:
>
> On Apr 25, 2012, at 10:42 AM, Felix Fietkau wrote:
>
>> On 2012-04-24 2:54 PM, John W. Linville wrote:
>>> On Tue, Apr 24, 2012 at 12:00:11PM +0200, Andreas Hartmann wrote:
>>>> Andrew Chant wrote:
>>>>> 3.4-rc4 doesn't work either.
>>>>> If I revert the patch on 3.4-rc4, the Intel card is able to associate again.
>>>>> -Andrew
>>>>>
>>>>> On Tue, Apr 24, 2012 at 12:11 AM, Andrew Chant <[email protected]> wrote:
>>>>>> Hello,
>>>>>> my Atheros AR9300 PCIe card (168c:0030) stopped working as an AP on
>>>>>> the 5GHz band between 3.3 and 3.4-rc2.
>>>>>> After 14 git bisects, I believe I have narrowed it down to the following patch:
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=293702a3fb75832613e2af097bdc3ac8ef775b33
>>>>>>
>>>>>> mac80211: use common radiotap code for cooked monitors
>>>>
>>>> Same problem here with ar9285 / 2.4GHz / eap-tls / 802.11n / hostapd
>>>> 0.7.3 / compat-wireless-3.4-rc3-1.tar.bz2
>>>>
>>>> Removing "mac80211: use common radiotap code for cooked monitors" solves
>>>> the problem here, too.
>>>>
>>>> Using rt2860 as AP seems not to be a problem.
>>>
>>> Sounds like we may need to revert it upstream. Johannes, any comments?
>> That's a known bug, which I submitted a fix for. When looking at the
>> 3.4-rc4 log, I don't see my fix in there. It was submitted as
>> "[PATCH] mac80211: fix truncated packets in cooked monitor rx"
>
>
> Just as another data-point, I'm using ath9k for an AR9300 Rev:3 chipset
> with compat-wireless-v3.4-rc3-1, and it doesn't work as an AP in any case:
>
> Stock code:
> fails
> Reverting [PATCH] mac80211: use common radiotap code for cooked monitors:
> fails
> Leaving the above in place and applying Felix's radiotap patch:
> fails
>
> I get a lot of these logs from hostapd:
>
> 1335397090.413064: Could not parse ProbeReq from 00:24:44:f5:e3:c2
>
> I'm using hostapd 0.7.3. If I rewind to an earlier "stable", it works -
> at least the AP works; there is a bug in client mode when connecting to
> a WEP AP, which is fixed in v3.4-rc3-1.
>
> Should I try switching from "stable" to "next"?
>
> --
> -bp
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html