Question on beacon-miss offloading.
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
So, I think I'll try to come up with some way to report proper tx-status for wmi-mgt-frames in my firmware....
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Michał
Quoted 33 lines · Michal Kazior
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
For what it's worth, I looked at the 4.0.4 ath10k yesterday, and it appears it ignores the message that the 10.1 firmware sends when beacon loss happens anyway. Maybe I misread the firmware code..it's a pile of indirection.
Do you know how the firmware is supposed to signal beacon loss to the host (from the host's perspective).
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 48 lines · Ben Greear
Quoted 38 lines · Michal Kazior
Quoted 23 lines · Ben Greear
Quoted 14 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Quoted 7 lines
For what it's worth, I looked at the 4.0.4 ath10k yesterday, and it appears it
ignores the message that the 10.1 firmware sends when beacon loss happens anyway. Maybe I misread the firmware code..it's a pile of indirection.Do you know how the firmware is supposed to signal beacon loss to the host (from the host's perspective).
Normally driver would advertise IEEE80211_HW_CONNECTION_MONITOR to disable mac80211 from tracking connection. and driver should call ieee80211_beacon_loss up on receiving beacon loss event from FW which triggers disconnection in mac80211.
Quoted 54 lines · Krishna Chaitanya
Quoted 53 lines · Ben Greear
Quoted 38 lines · Michal Kazior
Quoted 23 lines · Ben Greear
Quoted 14 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
For what it's worth, I looked at the 4.0.4 ath10k yesterday, and it appears it
ignores the message that the 10.1 firmware sends when beacon loss happens anyway. Maybe I misread the firmware code..it's a pile of indirection.
Quoted 7 lines
Quoted 2 lines
Do you know how the firmware is supposed to signal beacon loss to the host (from the host's perspective).
Normally driver would advertise
IEEE80211_HW_CONNECTION_MONITORto disable mac80211 from tracking connection. and driver should callieee80211_beacon_lossup on receiving beacon loss event from FW which triggers disconnection in mac80211.
I do not see any calls to beacon_loss() in the ath10k driver, so probably that firmware feature is not just fully wired up to the driver. Just as well since that firmware feature is disabled in my (-diet variant) firmware entirely.
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 33 lines · Michal Kazior
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Thanks for the hint. I was able to fix my firmware to properly return htt tx status, and now it appears to work properly.
A quick throughput test works as well, so hopefully no regressions.
I guess the NulFunc related comment is incorrect for 10.1 stock firmware?
Maybe some others?
static void ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
int ret = 0;
if (ar->htt.target_version_major >= 3) {
/* Since HTT 3.0 there is no separate mgmt tx command */
ret = ath10k_htt_tx(&ar->htt, skb);
goto exit;
}
if (ieee80211_is_mgmt(hdr->frame_control)) {
if (test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
ar->fw_features)) {
if (skb_queue_len(&ar->wmi_mgmt_tx_queue) >=
ATH10K_MAX_NUM_MGMT_PENDING) {
ath10k_warn(ar, "reached WMI management transmit queue limit\n");
ret = -EBUSY;
goto exit;
}
skb_queue_tail(&ar->wmi_mgmt_tx_queue, skb);
ieee80211_queue_work(ar->hw, &ar->wmi_mgmt_tx_work);
} else {
ret = ath10k_htt_mgmt_tx(&ar->htt, skb);
}
} else if (!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
ar->fw_features) &&
ieee80211_is_nullfunc(hdr->frame_control)) {
/* FW does not report tx status properly for NullFunc frames
* unless they are sent through mgmt tx path. mac80211 sends
* those frames when it detects link/beacon loss and depends
* on the tx status to be correct. */
ret = ath10k_htt_mgmt_tx(&ar->htt, skb);
} else {
ret = ath10k_htt_tx(&ar->htt, skb);
}Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 78 lines · Ben Greear
Quoted 33 lines · Michal Kazior
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Thanks for the hint. I was able to fix my firmware to properly return htt tx status, and now it appears to work properly.
A quick throughput test works as well, so hopefully no regressions.
I guess the NulFunc related comment is incorrect for 10.1 stock firmware?
Maybe some others?
static void
ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb){ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; int ret = 0; if (ar->htt.target_version_major >= 3) { /* Since HTT 3.0 there is no separate mgmt tx command */ ret = ath10k_htt_tx(&ar->htt, skb); goto exit; } if (ieee80211_is_mgmt(hdr->frame_control)) { if (test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features)) { if (skb_queue_len(&ar->wmi_mgmt_tx_queue) >= ATH10K_MAX_NUM_MGMT_PENDING) { ath10k_warn(ar, "reached WMI management transmit queue limit\n"); ret = -EBUSY; goto exit; } skb_queue_tail(&ar->wmi_mgmt_tx_queue, skb); ieee80211_queue_work(ar->hw, &ar->wmi_mgmt_tx_work); } else { ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } } else if (!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features) && ieee80211_is_nullfunc(hdr->frame_control)) {
Quoted 8 lines
/* FW does not report tx status properly for NullFunc frames
* unless they are sent through mgmt tx path. mac80211 sends
* those frames when it detects link/beacon loss and depends
* on the tx status to be correct. */
ret = ath10k_htt_mgmt_tx(&ar->htt, skb);
} else {
ret = ath10k_htt_tx(&ar->htt, skb);
}The NullFunc workaround was originally done for 999.999.0.636 but should be true for 10.1 as well with the sole exception the latter doesn't have htt-mgmt-tx to workaround the problem.
Michał
Quoted 88 lines · Michal Kazior
Quoted 78 lines · Ben Greear
Quoted 33 lines · Michal Kazior
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Thanks for the hint. I was able to fix my firmware to properly return htt tx status, and now it appears to work properly.
A quick throughput test works as well, so hopefully no regressions.
I guess the NulFunc related comment is incorrect for 10.1 stock firmware?
Maybe some others?
static void
ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb){ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; int ret = 0; if (ar->htt.target_version_major >= 3) { /* Since HTT 3.0 there is no separate mgmt tx command */ ret = ath10k_htt_tx(&ar->htt, skb); goto exit; } if (ieee80211_is_mgmt(hdr->frame_control)) { if (test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features)) { if (skb_queue_len(&ar->wmi_mgmt_tx_queue) >= ATH10K_MAX_NUM_MGMT_PENDING) { ath10k_warn(ar, "reached WMI management transmit queue limit\n"); ret = -EBUSY; goto exit; } skb_queue_tail(&ar->wmi_mgmt_tx_queue, skb); ieee80211_queue_work(ar->hw, &ar->wmi_mgmt_tx_work); } else { ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } } else if (!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features) && ieee80211_is_nullfunc(hdr->frame_control)) {Quoted 8 lines
/* FW does not report tx status properly for NullFunc frames * unless they are sent through mgmt tx path. mac80211 sends * those frames when it detects link/beacon loss and depends * on the tx status to be correct. */ ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } else { ret = ath10k_htt_tx(&ar->htt, skb); }
Quoted 3 lines
The NullFunc workaround was originally done for 999.999.0.636 but should be true for 10.1 as well with the sole exception the latter doesn't have htt-mgmt-tx to workaround the problem.
Is it correct to say that this logic is completely broken for stock 10.1 firmware because null-func frames are not management frames, so the packet goes out the ath10k_htt_mgmt_tx call, and stock 10.1 does not properly do tx status for htt-tx frames?
And slightly different question: Once I put in proper htt ACK reporting into my firmware, I notice that stations often loose connectivity when they are idle. I captured a sniff, and it appears the null-func packets are sent, but the header is not requesting an explicit ACK, and the AP does not ACK it, so connection is lost.
I guess that the null-func frames should be requesting explicit ACK?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 99 lines · Ben Greear
Quoted 88 lines · Michal Kazior
Quoted 78 lines · Ben Greear
Quoted 33 lines · Michal Kazior
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Thanks for the hint. I was able to fix my firmware to properly return htt tx status, and now it appears to work properly.
A quick throughput test works as well, so hopefully no regressions.
I guess the NulFunc related comment is incorrect for 10.1 stock firmware?
Maybe some others?
static void
ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb){ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; int ret = 0; if (ar->htt.target_version_major >= 3) { /* Since HTT 3.0 there is no separate mgmt tx command */ ret = ath10k_htt_tx(&ar->htt, skb); goto exit; } if (ieee80211_is_mgmt(hdr->frame_control)) { if (test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features)) { if (skb_queue_len(&ar->wmi_mgmt_tx_queue) >= ATH10K_MAX_NUM_MGMT_PENDING) { ath10k_warn(ar, "reached WMI management transmit queue limit\n"); ret = -EBUSY; goto exit; } skb_queue_tail(&ar->wmi_mgmt_tx_queue, skb); ieee80211_queue_work(ar->hw, &ar->wmi_mgmt_tx_work); } else { ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } } else if (!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features) && ieee80211_is_nullfunc(hdr->frame_control)) {Quoted 8 lines
/* FW does not report tx status properly for NullFunc frames * unless they are sent through mgmt tx path. mac80211 sends * those frames when it detects link/beacon loss and depends * on the tx status to be correct. */ ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } else { ret = ath10k_htt_tx(&ar->htt, skb); }Quoted 3 lines
The NullFunc workaround was originally done for 999.999.0.636 but should be true for 10.1 as well with the sole exception the latter doesn't have htt-mgmt-tx to workaround the problem.
Is it correct to say that this logic is completely broken for stock 10.1 firmware because null-func frames are not management frames, so the packet goes out the
ath10k_htt_mgmt_txcall, and stock 10.1 does not properly do tx status for htt-tx frames?
Quoted 7 lines
And slightly different question: Once I put in proper htt ACK reporting into my firmware, I notice that stations often loose connectivity when they are idle. I captured a sniff, and it appears the null-func packets are sent, but the header is not requesting an explicit ACK, and the AP does not ACK it, so connection is lost.
I guess that the null-func frames should be requesting explicit ACK?
This patch below (with firmware fix to make it actually pay attention to this special TID in station mode), fixes the null-func to be non-qos frames and get immediate ack. This in turn seems to fix the disconnect issue I was facing, though I need to test some more to be sure.
This seem reasonable, maybe even for upstream?
[greearb@ben-dt2 ath10k]$ git diff
drivers/net/wireless/ath/ath10k/mac.c +3 -0
@@ -2213,6 +2213,9 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)if (ieee80211_is_mgmt (hdr->frame_control))return HTT_DATA_TX_EXT_TID_MGMT ; +if (ieee80211_is_nullfunc (hdr->frame_control)) +return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST ; +if (!ieee80211_is_data_qos (hdr->frame_control))return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST ;
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 90 lines · Ben Greear
Quoted 89 lines · Ben Greear
Quoted 88 lines · Michal Kazior
Quoted 86 lines · Ben Greear
Quoted 33 lines · Michal Kazior
Quoted 20 lines · Ben Greear
Quoted 13 lines · Ben Greear
In my ath10k CT firmware, I am disabling the beacon-miss offloading to save space and because it will not work with lots of virtual stations.
But, it must be that I need some way to tell the stack that this feature is not enabled, because when suddenly kill my AP, then the ath10k station connected to it shows endless 'beacon loss' events in 'iw events' output, but it never actually loses connection.
Stock firmware works fine, so probably I just need to disable some feature flag when registering the ath10k hardware when using CT firmware.
Quoted 5 lines
With stock firmware, I see a quick dissassociation due to inactivity.
I am having poor luck finding how a driver tells the stack it has beacon miss offload or not, so, does anyone know how this is controlled?
Quoted 6 lines
I still am not sure why stock firmware works, but it appears the reason mine is failing is that the ACK status for mgt frames is always set to TRUE since the ath10k wmi-mgt-tx API is so lame. So, mac80211 does a probe, ath10k lies and says it was acked, and mac80211 then things all is well for another few seconds.
mac80211 shouldn't do a Probe Req to an AP on beacon loss because ath10k advertises it supports tx-status report. Hence mac80211 should use NullFunc frames which shouldn't go through wmi-mgmt-tx but htt tx-frm.
Quoted 5 lines
But then again: NullFunc status reporting via htt tx-frm was broken on 10.1 if memory serves right. I believe it was fixed in 10.2 or 10.2.4.
This problem has been effectively obscured on stock 10.1 by the offloaded beacon miss.
Thanks for the hint. I was able to fix my firmware to properly return htt tx status, and now it appears to work properly.
A quick throughput test works as well, so hopefully no regressions.
I guess the NulFunc related comment is incorrect for 10.1 stock firmware?
Maybe some others?
static void
ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb){ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; int ret = 0; if (ar->htt.target_version_major >= 3) { /* Since HTT 3.0 there is no separate mgmt tx command */ ret = ath10k_htt_tx(&ar->htt, skb); goto exit; } if (ieee80211_is_mgmt(hdr->frame_control)) { if (test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features)) { if (skb_queue_len(&ar->wmi_mgmt_tx_queue) >= ATH10K_MAX_NUM_MGMT_PENDING) { ath10k_warn(ar, "reached WMI management transmit queue limit\n"); ret = -EBUSY; goto exit; } skb_queue_tail(&ar->wmi_mgmt_tx_queue, skb); ieee80211_queue_work(ar->hw, &ar->wmi_mgmt_tx_work); } else { ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } } else if (!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features) && ieee80211_is_nullfunc(hdr->frame_control)) { /* FW does not report tx status properly for NullFunc frames * unless they are sent through mgmt tx path. mac80211 sends * those frames when it detects link/beacon loss and depends * on the tx status to be correct. */ ret = ath10k_htt_mgmt_tx(&ar->htt, skb); } else { ret = ath10k_htt_tx(&ar->htt, skb); }
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
The NullFunc workaround was originally done for 999.999.0.636 but should be true for 10.1 as well with the sole exception the latter doesn't have htt-mgmt-tx to workaround the problem.
Is it correct to say that this logic is completely broken for stock 10.1 firmware because null-func frames are not management frames, so the packet goes out the
ath10k_htt_mgmt_txcall, and stock 10.1 does not properly do tx status for htt-tx frames?
The has-wmi-mgmt-tx was originally designed to identify FW supporting htt-mgmt-tx. It ended up to be used (implicitly) as a part of the NullFunc workaround.
Hmm.. I guess it's not really ideal now because latest 10.2.4 FW which supports htt-mgmt-tx doesn't need the workaround (htt-tx report correct tx-status for NullFuncs)..
Quoted 21 lines
Quoted 7 lines
And slightly different question: Once I put in proper htt ACK reporting into my firmware, I notice that stations often loose connectivity when they are idle. I captured a sniff, and it appears the null-func packets are sent, but the header is not requesting an explicit ACK, and the AP does not ACK it, so connection is lost.
I guess that the null-func frames should be requesting explicit ACK?
This patch below (with firmware fix to make it actually pay attention to this special TID in station mode), fixes the null-func to be non-qos frames and get immediate ack. This in turn seems to fix the disconnect issue I was facing, though I need to test some more to be sure.
This seem reasonable, maybe even for upstream?
[greearb@ben-dt2 ath10k]$ git diff
drivers/net/wireless/ath/ath10k/mac.c +0
-0
drivers/net/wireless/ath/ath10k/mac.c static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr) · line 2218
Quoted 6 lines
drivers/net/wireless/ath/ath10k/mac.c +3
-0@@ -2213,6 +2213,9 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)if (ieee80211_is_mgmt (hdr->frame_control))return HTT_DATA_TX_EXT_TID_MGMT ; +if (ieee80211_is_nullfunc (hdr->frame_control)) +return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST ; +
That's weird.. QoS NullFunc frames are already converted to non-QoS frames, see ath10k_tx_h_nwifi():
/* Some firmware revisions don't handle sending QoS NullFunc well.
* These frames are mainly used for CQM purposes so it doesn't really
* matter whether QoS NullFunc or NullFunc are sent.
*/
hdr = (void *)skb->data;
if (ieee80211_is_qos_nullfunc(hdr->frame_control))
cb->htt.tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;Or is it that ath10k_tx_h_get_tid() has a bug that ends up assigning an invalid tid for non-QoS NullFunc frames? If so I guess your patch would be okay with some comments/commit-log explaining why/what was wrong.
Michał
Quoted 16 lines · Michal Kazior
Quoted 16 lines
This patch below (with firmware fix to make it actually pay attention to this special TID in station mode), fixes the null-func to be non-qos frames and get immediate ack. This in turn seems to fix the disconnect issue I was facing, though I need to test some more to be sure.
This seem reasonable, maybe even for upstream?
[greearb@ben-dt2 ath10k]$ git diff
drivers/net/wireless/ath/ath10k/mac.c +0
-0@@ -2213,6 +2213,9 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)if (ieee80211_is_mgmt (hdr->frame_control))return HTT_DATA_TX_EXT_TID_MGMT ;
Quoted 6 lines
drivers/net/wireless/ath/ath10k/mac.c static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr) · line 2218
Quoted 3 lines
drivers/net/wireless/ath/ath10k/mac.c +3
-0+if (ieee80211_is_nullfunc (hdr->frame_control)) +return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST ; +That's weird.. QoS NullFunc frames are already converted to non-QoS frames, see
ath10k_tx_h_nwifi():
True, but the 4.0.4 kernel sends down non-qos null-func frames as far as I can tell, at least when doing connection probing.
In my case, my kernel was sending non-qos nullfunc frame to firmware, but then firmware stuck it on BE queue and made it QoS.
Quoted 8 lines
/* Some firmware revisions don't handle sending QoS NullFunc well.
* These frames are mainly used for CQM purposes so it doesn't really
* matter whether QoS NullFunc or NullFunc are sent.
*/
hdr = (void *)skb->data;
if (ieee80211_is_qos_nullfunc(hdr->frame_control))
cb->htt.tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;Quoted 4 lines
Or is it that
ath10k_tx_h_get_tid()has a bug that ends up assigning an invalid tid for non-QoS NullFunc frames? If so I guess your patch would be okay with some comments/commit-log explaining why/what was wrong.
I tried very recent upstream ath kernel, and stock firmware-2.bin, and it seems to generate null-func frames fine. I'll go back at look at my recent FW and kernel changes in more detail now that I understand the problem better and see if I can figure out what is going on...
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 25 lines · Ben Greear
Quoted 16 lines · Michal Kazior
Quoted 16 lines
This patch below (with firmware fix to make it actually pay attention to this special TID in station mode), fixes the null-func to be non-qos frames and get immediate ack. This in turn seems to fix the disconnect issue I was facing, though I need to test some more to be sure.
This seem reasonable, maybe even for upstream?
[greearb@ben-dt2 ath10k]$ git diff
drivers/net/wireless/ath/ath10k/mac.c +0
-0@@ -2213,6 +2213,9 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)if (ieee80211_is_mgmt (hdr->frame_control))return HTT_DATA_TX_EXT_TID_MGMT ;Quoted 6 lines
drivers/net/wireless/ath/ath10k/mac.c static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr) · line 2218
Quoted 3 lines
drivers/net/wireless/ath/ath10k/mac.c +3
-0+if (ieee80211_is_nullfunc (hdr->frame_control)) +return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST ; +That's weird.. QoS NullFunc frames are already converted to non-QoS frames, see
ath10k_tx_h_nwifi():
Quoted 5 lines
True, but the 4.0.4 kernel sends down non-qos null-func frames as far as I can tell, at least when doing connection probing.
In my case, my kernel was sending non-qos nullfunc frame to firmware, but then firmware stuck it on BE queue and made it QoS.
Stock 4.0.4 and stock firmware-2.bin have the same 'nullfunc sent as qos and no immediate ack' bug, so it must be something that was fixed or changed between 4.0.4 and the 4.1.x ath tree.
Thanks,
Ben
Quoted 21 lines
Quoted 8 lines
/* Some firmware revisions don't handle sending QoS NullFunc well. * These frames are mainly used for CQM purposes so it doesn't really * matter whether QoS NullFunc or NullFunc are sent. */ hdr = (void *)skb->data; if (ieee80211_is_qos_nullfunc(hdr->frame_control)) cb->htt.tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;Quoted 4 lines
Or is it that
ath10k_tx_h_get_tid()has a bug that ends up assigning an invalid tid for non-QoS NullFunc frames? If so I guess your patch would be okay with some comments/commit-log explaining why/what was wrong.I tried very recent upstream ath kernel, and stock firmware-2.bin, and it seems to generate null-func frames fine. I'll go back at look at my recent FW and kernel changes in more detail now that I understand the problem better and see if I can figure out what is going on...
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com