After my latest git pull to the kernel version 2.6.33-rc1-wl
no client was able to connect to my hostapd (v0.6.9) AP.
I found a lot of the following entries in the syslog:
wlan0: STA xx:xx:xx:xx:xx:xx
IEEE 802.11: did not acknowledge authentication response
I bisected the problem to the commit e77f5ff92f5ef43c842e97136edcb68c61afe588
above.
After I removed the lines below in rt2x00dev.c:
rt2x00dev->hw->extra_tx_headroom =
max_t(unsigned int, IEEE80211_TX_STATUS_HEADROOM,
rt2x00dev->ops->extra_tx_headroom);
/*
* Take TX headroom required for alignment into account.
*/
if (test_bit(DRIVER_REQUIRE_L2PAD, &rt2x00dev->flags))
rt2x00dev->hw->extra_tx_headroom += RT2X00_L2PAD_SIZE;
else if (test_bit(DRIVER_REQUIRE_DMA, &rt2x00dev->flags))
rt2x00dev->hw->extra_tx_headroom += RT2X00_ALIGN_SIZE;
added the line:
rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
and compiled the kernel 2.6.33-rc2 again, all worked fine.
On 12/20/09 16:42, Markus Baier wrote:
> After my latest git pull to the kernel version 2.6.33-rc1-wl
> no client was able to connect to my hostapd (v0.6.9) AP.
> I found a lot of the following entries in the syslog:
>
> wlan0: STA xx:xx:xx:xx:xx:xx
> IEEE 802.11: did not acknowledge authentication response
>
> I bisected the problem to the commit e77f5ff92f5ef43c842e97136edcb68c61afe588
> above.
>
> After I removed the lines below in rt2x00dev.c:
> rt2x00dev->hw->extra_tx_headroom =
> max_t(unsigned int, IEEE80211_TX_STATUS_HEADROOM,
> rt2x00dev->ops->extra_tx_headroom);
>
> /*
> * Take TX headroom required for alignment into account.
> */
> if (test_bit(DRIVER_REQUIRE_L2PAD, &rt2x00dev->flags))
> rt2x00dev->hw->extra_tx_headroom += RT2X00_L2PAD_SIZE;
> else if (test_bit(DRIVER_REQUIRE_DMA, &rt2x00dev->flags))
> rt2x00dev->hw->extra_tx_headroom += RT2X00_ALIGN_SIZE;
>
> added the line:
> rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
>
> and compiled the kernel 2.6.33-rc2 again, all worked fine.
>
That is very strange as this patch was meant to send TX statuses of frames
towards monitor interfaces (which is what hostapd is using).
What kind of rt2x00 device are you using (and which of the rt2x00 drivers)?
Are there any messages in dmesg when this happens?
Can you check whether there are any messages in dmesg in the working situation?
---
Gertjan.
Quoting Gertjan van Wingerde <[email protected]>:
> Doh, that's it. Here we should indeed only take the real extra TX
> headroom required by
> the driver into account. Seems like I goofed up in a preparatory
> patch that centralized
> setting of rt2x00dev->hw->extra_tx_headroom.
>
> Can you confirm that everything works okay with the original code
> and this patch applied?
The managed mode is working fine for me.
I think it would be a good idea to test all modes and make sure that
the patch for adding extra headroom does what it should (in addition
to not breaking things).
--
Regards,
Pavel Roskin
On 12/22/09 06:25, Pavel Roskin wrote:
> Quoting Gertjan van Wingerde <[email protected]>:
>
>>> Perhaps non-zero headroom is not handled correctly?
>>>
>>
>> Hmmm, perhaps the problem is that the headroom is not a multiple of 4.
>> Can you check what happens when you set the extra_tx_headroom fixed
>> to e.g. 20?
>
> I tried 64 and 2, and neither worked. rt2x00dev->ops->extra_tx_headroom
> is 0 for me. When the rt2x00dev->hw->extra_tx_headroom is 2, I observed
> invalid packets being emitted (using another interface). The packets
> have two bytes inserted in the beginning of the frame:
>
> 0000 00 00 1c 00 6f 48 00 00 fc de ee 13 00 00 00 00 ....oH.. ........
> 0010 10 02 85 09 a0 00 b1 b7 00 00 00 00 00 00 40 00 ........ ......@.
> radiotap, 28 bytes ---------------------->
> 2 extra bytes <--->
> correct 802.11 header <----
> 0020 00 00 ff ff ff ff ff ff 00 d0 41 af ad 2c ff ff ........ ..A..,..
> 0030 ff ff cf 02 c0 02 00 05 77 62 65 6e 64 01 08 02 ........ wbend...
> 0040 04 0b 16 0c 12 18 24 32 04 30 48 e7 f8 07 9d ......$2 .0H....
>
> Here's a patch that is working for me, but I would not vouch for its
> correctness. Signing off just in case it happens to be correct ;-)
>
>
> rt2x00: use correct headroom for transmission
>
> Use rt2x00dev->ops->extra_tx_headroom, not
> rt2x00dev->hw->extra_tx_headroom in the tx code, as the later includes
> headroom only meant for the monitor mode.
>
> Signed-off-by: Pavel Roskin <[email protected]>
Doh, that's it. Here we should indeed only take the real extra TX headroom required by
the driver into account. Seems like I goofed up in a preparatory patch that centralized
setting of rt2x00dev->hw->extra_tx_headroom.
Can you confirm that everything works okay with the original code and this patch applied?
In any way:
Acked-by: Gertjan van Wingerde <[email protected]>
John, with this you can reinstate the original patch as well. Let me know if you want
me to resubmit that one with this one included in it.
> ---
> drivers/net/wireless/rt2x00/rt2x00queue.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
> index 3d8fb68..0b4801a 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00queue.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
> @@ -104,7 +104,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
> * is also mapped to the DMA so it can be used for transfering
> * additional descriptor information to the hardware.
> */
> - skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
> + skb_push(skb, rt2x00dev->ops->extra_tx_headroom);
>
> skbdesc->skb_dma =
> dma_map_single(rt2x00dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
> @@ -112,7 +112,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
> /*
> * Restore data pointer to original location again.
> */
> - skb_pull(skb, rt2x00dev->hw->extra_tx_headroom);
> + skb_pull(skb, rt2x00dev->ops->extra_tx_headroom);
>
> skbdesc->flags |= SKBDESC_DMA_MAPPED_TX;
> }
> @@ -134,7 +134,7 @@ void rt2x00queue_unmap_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
> * by the driver, but it was actually mapped to DMA.
> */
> dma_unmap_single(rt2x00dev->dev, skbdesc->skb_dma,
> - skb->len + rt2x00dev->hw->extra_tx_headroom,
> + skb->len + rt2x00dev->ops->extra_tx_headroom,
> DMA_TO_DEVICE);
> skbdesc->flags &= ~SKBDESC_DMA_MAPPED_TX;
> }
>
On Mon, Dec 21, 2009 at 05:26:55PM +0100, Gertjan van Wingerde wrote:
> On 12/21/09 07:33, Pavel Roskin wrote:
> > My debugging shows that the headroom is 0 with the "patch". Without it,
> > the headroom is 17 (13 from IEEE80211_TX_STATUS_HEADROOM plus 4 from
> > RT2X00_ALIGN_SIZE).
> >
> > Perhaps non-zero headroom is not handled correctly?
> >
>
> Hmmm, perhaps the problem is that the headroom is not a multiple of 4.
> Can you check what happens when you set the extra_tx_headroom fixed to e.g. 20?
>
> The driver should be able to handle this, but maybe there is something wrong
> with the alignment.
For the record, I have dropped this patch. Please feel free to
resubmit a working version.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Gertjan van Wingerde <gwingerde@...> writes:
> Can you confirm that everything works okay with the original code
> and this patch applied?
I restored the original patch from 2.6.33-rc1-wl
and applied the patch from Pavel Roskin.
Now it works. Thanks!
Regards
Markus
Quoting Gertjan van Wingerde <[email protected]>:
>> Perhaps non-zero headroom is not handled correctly?
>>
>
> Hmmm, perhaps the problem is that the headroom is not a multiple of 4.
> Can you check what happens when you set the extra_tx_headroom fixed
> to e.g. 20?
I tried 64 and 2, and neither worked. rt2x00dev->ops->extra_tx_headroom
is 0 for me. When the rt2x00dev->hw->extra_tx_headroom is 2, I observed
invalid packets being emitted (using another interface). The packets
have two bytes inserted in the beginning of the frame:
0000 00 00 1c 00 6f 48 00 00 fc de ee 13 00 00 00 00 ....oH.. ........
0010 10 02 85 09 a0 00 b1 b7 00 00 00 00 00 00 40 00 ........ ......@.
radiotap, 28 bytes ---------------------->
2 extra bytes <--->
correct 802.11 header <----
0020 00 00 ff ff ff ff ff ff 00 d0 41 af ad 2c ff ff ........ ..A..,..
0030 ff ff cf 02 c0 02 00 05 77 62 65 6e 64 01 08 02 ........ wbend...
0040 04 0b 16 0c 12 18 24 32 04 30 48 e7 f8 07 9d ......$2 .0H....
Here's a patch that is working for me, but I would not vouch for its
correctness. Signing off just in case it happens to be correct ;-)
rt2x00: use correct headroom for transmission
Use rt2x00dev->ops->extra_tx_headroom, not
rt2x00dev->hw->extra_tx_headroom in the tx code, as the later includes
headroom only meant for the monitor mode.
Signed-off-by: Pavel Roskin <[email protected]>
---
drivers/net/wireless/rt2x00/rt2x00queue.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 3d8fb68..0b4801a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -104,7 +104,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
* is also mapped to the DMA so it can be used for transfering
* additional descriptor information to the hardware.
*/
- skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
+ skb_push(skb, rt2x00dev->ops->extra_tx_headroom);
skbdesc->skb_dma =
dma_map_single(rt2x00dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
@@ -112,7 +112,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
/*
* Restore data pointer to original location again.
*/
- skb_pull(skb, rt2x00dev->hw->extra_tx_headroom);
+ skb_pull(skb, rt2x00dev->ops->extra_tx_headroom);
skbdesc->flags |= SKBDESC_DMA_MAPPED_TX;
}
@@ -134,7 +134,7 @@ void rt2x00queue_unmap_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
* by the driver, but it was actually mapped to DMA.
*/
dma_unmap_single(rt2x00dev->dev, skbdesc->skb_dma,
- skb->len + rt2x00dev->hw->extra_tx_headroom,
+ skb->len + rt2x00dev->ops->extra_tx_headroom,
DMA_TO_DEVICE);
skbdesc->flags &= ~SKBDESC_DMA_MAPPED_TX;
}
--
Regards,
Pavel Roskin
On 12/21/09 07:33, Pavel Roskin wrote:
> Quoting Gertjan van Wingerde <[email protected]>:
>
>> On 12/20/09 16:42, Markus Baier wrote:
>>> After my latest git pull to the kernel version 2.6.33-rc1-wl
>>> no client was able to connect to my hostapd (v0.6.9) AP.
>>> I found a lot of the following entries in the syslog:
>>>
>>> wlan0: STA xx:xx:xx:xx:xx:xx
>>> IEEE 802.11: did not acknowledge authentication response
>
> I'm also having problems with rt2x00 support the current
> wireless-testing, but in the station mode. The device is using rt61pci
> driver. Association to an AP with WEP fails.
>
> [ 147.930019] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 1)
> [ 148.130010] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 2)
> [ 148.330009] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 3)
> [ 148.530008] wlan2: direct probe to AP 00:11:6b:28:0b:92 timed out
> [ 152.942516] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 1)
> [ 153.142512] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 2)
> [ 153.340011] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 3)
> [ 153.540008] wlan2: direct probe to AP 00:11:6b:28:0b:92 timed out
>
> It worked fine with wireless-testing when it was 2.6.32 based.
>
>>> After I removed the lines below in rt2x00dev.c:
>
> That "patch" is helping me too! The association is working now.
>
>> That is very strange as this patch was meant to send TX statuses of
>> frames
>> towards monitor interfaces (which is what hostapd is using).
>
> I'm not using monitor mode. I only have one vif in the station mode.
>
> My debugging shows that the headroom is 0 with the "patch". Without it,
> the headroom is 17 (13 from IEEE80211_TX_STATUS_HEADROOM plus 4 from
> RT2X00_ALIGN_SIZE).
>
> Perhaps non-zero headroom is not handled correctly?
>
Hmmm, perhaps the problem is that the headroom is not a multiple of 4.
Can you check what happens when you set the extra_tx_headroom fixed to e.g. 20?
The driver should be able to handle this, but maybe there is something wrong
with the alignment.
---
Gertjan.
On 12/22/09 11:55, Markus Baier wrote:
> Gertjan van Wingerde <gwingerde@...> writes:
>
>> Can you confirm that everything works okay with the original code
>> and this patch applied?
>
> I restored the original patch from 2.6.33-rc1-wl
> and applied the patch from Pavel Roskin.
> Now it works. Thanks!
>
OK. Thanks for verifying.
And many thanks for Pavel to come up this quickly with a patch to fix this.
---
Gertjan.
On 12/21/09 20:17, John W. Linville wrote:
> On Mon, Dec 21, 2009 at 05:26:55PM +0100, Gertjan van Wingerde wrote:
>> On 12/21/09 07:33, Pavel Roskin wrote:
>
>>> My debugging shows that the headroom is 0 with the "patch". Without it,
>>> the headroom is 17 (13 from IEEE80211_TX_STATUS_HEADROOM plus 4 from
>>> RT2X00_ALIGN_SIZE).
>>>
>>> Perhaps non-zero headroom is not handled correctly?
>>>
>>
>> Hmmm, perhaps the problem is that the headroom is not a multiple of 4.
>> Can you check what happens when you set the extra_tx_headroom fixed to e.g. 20?
>>
>> The driver should be able to handle this, but maybe there is something wrong
>> with the alignment.
>
> For the record, I have dropped this patch. Please feel free to
> resubmit a working version.
>
Thanks. I was about to suggest the same.
---
Gertjan.
Gertjan van Wingerde <gwingerde@...> writes:
> What kind of rt2x00 device are you using (and which of the rt2x00 drivers)?
The device is a PCMICA card with the RT2561 chipset.
The driver is the rt61pci driver.
>>lsmod
Module Size Used by
rt61pci 18193 0
crc_itu_t 1017 1 rt61pci
rt2x00pci 4189 1 rt61pci
rt2x00lib 22940 2 rt61pci,rt2x00pci
eeprom_93cx6 960 1 rt61pci
> Are there any messages in dmesg when this happens?
No, there are no messages in dmesg
There are no differences in the dmesg output between
the working and the broken kernel
Here is the dmesg output:
rt61pci 0000:02:00.0: enabling device (0000 -> 0002)
rt61pci 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
rt61pci 0000:02:00.0: setting latency timer to 64
phy0 -> rt61pci_validate_eeprom: EEPROM recovery - NIC: 0xff80
phy0 -> rt61pci_validate_eeprom: EEPROM recovery - Led: 0xe0ff
phy0 -> rt2x00_print_chip: Info - Chipset detected - rt: 0302, rf: 0003, rev:
0002561c.
phy0: Selected rate control algorithm 'minstrel'
Registered led device: rt61pci-phy0::radio
Registered led device: rt61pci-phy0::assoc
phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt2561.bin'.
rt61pci 0000:02:00.0: firmware: requesting rt2561.bin
phy0 -> rt2x00lib_request_firmware: Info - Firmware detected - version: 0.8.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4,
Aifs: 2, TXop: 102.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5,
Aifs: 2, TXop: 188.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10,
Aifs: 3, TXop: 0.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10,
Aifs: 7, TXop: 0.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4,
Aifs: 2, TXop: 102.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5,
Aifs: 2, TXop: 188.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10,
Aifs: 3, TXop: 0.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10,
Aifs: 7, TXop: 0.
cfg80211: Calling CRDA for country: DE
cfg80211: Regulatory domain changed to country: DE
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
device wlan0 entered promiscuous mode
br0: port 2(wlan0) entering learning state
br0: port 1(eth0) entering forwarding state
br0: port 2(wlan0) entering forwarding state
------------------------------------------------------------------------
But there are differences in the hostapd log.
Here is the log output from the broken system:
>>hostapd -tddd /etc/hostapd/wpa2_ap.conf
....
1261351288.111499: MGMT (TX callback) fail
1261351288.111513: mgmt::proberesp cb
1261351290.256576: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261351290.257122: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261351290.257735: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261351290.258351: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261351290.258971: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261351290.268092: MGMT (TX callback) fail
1261351290.268116: mgmt::proberesp cb
1261351290.277054: MGMT (TX callback) fail
1261351290.277074: mgmt::proberesp cb
1261351290.285832: MGMT (TX callback) fail
1261351290.285848: mgmt::proberesp cb
1261351290.294522: MGMT (TX callback) fail
1261351290.294538: mgmt::proberesp cb
1261351290.303364: MGMT (TX callback) fail
1261351290.303379: mgmt::proberesp cb
1261351291.334698: MGMT
1261351291.334719: mgmt::auth
1261351291.334727: authentication: STA=xx:xx:xx:xx:xx:xx auth_alg=0
auth_transaction=1 status_code=0 wep=0
1261351291.334769: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authentication OK
(open system)
1261351291.334795: wlan0: STA xx:xx:xx:xx:xx:xx MLME:
MLME-AUTHENTICATE.indication(xx:xx:xx:xx:xx:xx, OPEN_SYSTEM)
1261351291.334817: wlan0: STA xx:xx:xx:xx:xx:xx MLME:
MLME-DELETEKEYS.request(xx:xx:xx:xx:xx:xx)
1261351291.334830: authentication reply: STA=xx:xx:xx:xx:xx:xx auth_alg=0
auth_transaction=2 resp=0 (IE len=0)
1261351291.339781: MGMT (TX callback) fail
1261351291.339794: mgmt::auth cb
1261351291.339813: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
acknowledge authentication response
....
------------------------------------------------------------------------
Here the log output from the working system:
>>hostapd -tddd /etc/hostapd/wpa2_ap.conf
....
1261353953.151469: MGMT (TX callback) ACK
1261353956.790339: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261353956.790871: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261353956.791481: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261353956.792098: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261353956.792717: STA xx:xx:xx:xx:xx:xx sent probe request for our SSID
1261353956.794326: MGMT (TX callback) ACK
1261353956.794339: mgmt::proberesp cb
1261353956.795806: MGMT (TX callback) ACK
1261353956.795827: mgmt::proberesp cb
1261353956.797184: MGMT (TX callback) ACK
1261353956.797195: mgmt::proberesp cb
1261353956.798558: MGMT (TX callback) ACK
1261353956.798569: mgmt::proberesp cb
1261353956.799907: MGMT (TX callback) ACK
1261353956.799918: mgmt::proberesp cb
1261353957.868214: MGMT
1261353957.868236: mgmt::auth
1261353957.868245: authentication: STA=xx:xx:xx:xx:xx:xx auth_alg=0
auth_transaction=1 status_code=0 wep=0
1261353957.868266: New STA
1261353957.868313: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authentication OK
(open system)
1261353957.868344: wlan0: STA xx:xx:xx:xx:xx:xx MLME:
MLME-AUTHENTICATE.indication(xx:xx:xx:xx:xx:xx, OPEN_SYSTEM)
1261353957.868366: wlan0: STA xx:xx:xx:xx:xx:xx MLME:
MLME-DELETEKEYS.request(xx:xx:xx:xx:xx:xx)
1261353957.868385: authentication reply: STA=xx:xx:xx:xx:xx:xx auth_alg=0
auth_transaction=2 resp=0 (IE len=0)
1261353957.869332: MGMT (TX callback) ACK
1261353957.869347: mgmt::auth cb
1261353957.869368: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
....
Please tell me if some information are missing.
Regards,
Markus
Quoting Gertjan van Wingerde <[email protected]>:
> On 12/20/09 16:42, Markus Baier wrote:
>> After my latest git pull to the kernel version 2.6.33-rc1-wl
>> no client was able to connect to my hostapd (v0.6.9) AP.
>> I found a lot of the following entries in the syslog:
>>
>> wlan0: STA xx:xx:xx:xx:xx:xx
>> IEEE 802.11: did not acknowledge authentication response
I'm also having problems with rt2x00 support the current
wireless-testing, but in the station mode. The device is using
rt61pci driver. Association to an AP with WEP fails.
[ 147.930019] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 1)
[ 148.130010] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 2)
[ 148.330009] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 3)
[ 148.530008] wlan2: direct probe to AP 00:11:6b:28:0b:92 timed out
[ 152.942516] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 1)
[ 153.142512] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 2)
[ 153.340011] wlan2: direct probe to AP 00:11:6b:28:0b:92 (try 3)
[ 153.540008] wlan2: direct probe to AP 00:11:6b:28:0b:92 timed out
It worked fine with wireless-testing when it was 2.6.32 based.
>> After I removed the lines below in rt2x00dev.c:
That "patch" is helping me too! The association is working now.
> That is very strange as this patch was meant to send TX statuses of frames
> towards monitor interfaces (which is what hostapd is using).
I'm not using monitor mode. I only have one vif in the station mode.
My debugging shows that the headroom is 0 with the "patch". Without
it, the headroom is 17 (13 from IEEE80211_TX_STATUS_HEADROOM plus 4
from RT2X00_ALIGN_SIZE).
Perhaps non-zero headroom is not handled correctly?
--
Regards,
Pavel Roskin