QoS Control Field Stripped Off

QoS Control Field Stripped Off

[Yeoh Chun-Yeow]

Hi, all

Anyone knows whether it is possible to modify the QoS Control field in
the Tx Frame.

Currently, the QoS control field is stripped off before passing to FW.
I would like to set the bit-8 of QoS control field to indicate the
presence of mesh control field.

Thanks

Regards,
Chun-Yeow

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Michal Kazior]

On 19 February 2014 05:11, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
> Hi, all
>
> Anyone knows whether it is possible to modify the QoS Control field in
> the Tx Frame.
>
> Currently, the QoS control field is stripped off before passing to FW.
> I would like to set the bit-8 of QoS control field to indicate the
> presence of mesh control field.

From what I know HW generates QoS Control Field for nwifi tx format
and I don't think there's a way around that.

Your best bet is to get raw tx format working although last time I
checked it crashed FW.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Yeoh Chun-Yeow]

> From what I know HW generates QoS Control Field for nwifi tx format
> and I don't think there's a way around that.
>
> Your best bet is to get raw tx format working although last time I
> checked it crashed FW.

I try to set the ATH10K_HW_TXRX_RAW for tx format. Unfortunately, the
frame is not transmitted at all. So assume the FW not supports this.

FYI, I need to use FW version 999.999.0.636 since it is best for IBSS mode.

-----
Chun-Yeow

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Michal Kazior]

On 19 February 2014 08:59, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
>> From what I know HW generates QoS Control Field for nwifi tx format
>> and I don't think there's a way around that.
>>
>> Your best bet is to get raw tx format working although last time I
>> checked it crashed FW.
>
> I try to set the ATH10K_HW_TXRX_RAW for tx format. Unfortunately, the
> frame is not transmitted at all. So assume the FW not supports this.

Did you remove the call to ath10k_tx_h_qos_workaround() in ath10k_tx()?

Did you get any htt tx completion for the frame (look for `htt tx
completion msdu_id` and `htt tx alloc msdu_id` in traces/logs)? What
was the status of it?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Yeoh Chun-Yeow]

> Did you remove the call to ath10k_tx_h_qos_workaround() in ath10k_tx()?
Yes. I disable this.

> Did you get any htt tx completion for the frame (look for `htt tx
> completion msdu_id` and `htt tx alloc msdu_id` in traces/logs)? What
> was the status of it?
Try to capture using wireshark and no Tx frames. The following log observed:

[  272.340000] ath10k: htt rx, msg_type: 0x1
[  272.340000] ath10k: htt rx mgmt ctrl
[  272.340000] ath10k: htt tx alloc msdu_id 0
[  272.340000] ath10k: tx-msdu 0x71e2e10
[  272.340000] ath10k: htt data tx using tid 0
[  272.340000] ath10k: htt data tx not mgmt [additional log to
indicate data and not mgmt]
[  272.340000] ath10k: htt rx, msg_type: 0x7
[  272.340000] ath10k: htt tx completion num_msdus 1
[  272.340000] ath10k: htt tx completion msdu_id 0 discard 0 no_ack 0
[  272.340000] ath10k: htt tx free msdu_id 0

So, FW drops the Tx raw frame, even though the htt tx indicates completion?

----
Chun-Yeow

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Michal Kazior]

On 19 February 2014 09:45, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
>> Did you remove the call to ath10k_tx_h_qos_workaround() in ath10k_tx()?
> Yes. I disable this.
>
>> Did you get any htt tx completion for the frame (look for `htt tx
>> completion msdu_id` and `htt tx alloc msdu_id` in traces/logs)? What
>> was the status of it?
> Try to capture using wireshark and no Tx frames. The following log observed:
>
> [  272.340000] ath10k: htt rx, msg_type: 0x1
> [  272.340000] ath10k: htt rx mgmt ctrl
> [  272.340000] ath10k: htt tx alloc msdu_id 0
> [  272.340000] ath10k: tx-msdu 0x71e2e10
> [  272.340000] ath10k: htt data tx using tid 0
> [  272.340000] ath10k: htt data tx not mgmt [additional log to
> indicate data and not mgmt]
> [  272.340000] ath10k: htt rx, msg_type: 0x7
> [  272.340000] ath10k: htt tx completion num_msdus 1
> [  272.340000] ath10k: htt tx completion msdu_id 0 discard 0 no_ack 0
> [  272.340000] ath10k: htt tx free msdu_id 0
>
> So, FW drops the Tx raw frame, even though the htt tx indicates completion?

This might be HW itself as well. I'm adding Ben to the discussion.

Ben: You've done some research on tx/rx in firmware to get software
encryption in ath10k going, right? Did you play with raw tx format or
see any obstacles in the code that could prevent it from working?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Ben Greear]

On 02/19/2014 01:37 AM, Michal Kazior wrote:
> On 19 February 2014 09:45, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
>>> Did you remove the call to ath10k_tx_h_qos_workaround() in ath10k_tx()?
>> Yes. I disable this.
>>
>>> Did you get any htt tx completion for the frame (look for `htt tx
>>> completion msdu_id` and `htt tx alloc msdu_id` in traces/logs)? What
>>> was the status of it?
>> Try to capture using wireshark and no Tx frames. The following log observed:
>>
>> [  272.340000] ath10k: htt rx, msg_type: 0x1
>> [  272.340000] ath10k: htt rx mgmt ctrl
>> [  272.340000] ath10k: htt tx alloc msdu_id 0
>> [  272.340000] ath10k: tx-msdu 0x71e2e10
>> [  272.340000] ath10k: htt data tx using tid 0
>> [  272.340000] ath10k: htt data tx not mgmt [additional log to
>> indicate data and not mgmt]
>> [  272.340000] ath10k: htt rx, msg_type: 0x7
>> [  272.340000] ath10k: htt tx completion num_msdus 1
>> [  272.340000] ath10k: htt tx completion msdu_id 0 discard 0 no_ack 0
>> [  272.340000] ath10k: htt tx free msdu_id 0
>>
>> So, FW drops the Tx raw frame, even though the htt tx indicates completion?
> 
> This might be HW itself as well. I'm adding Ben to the discussion.
> 
> Ben: You've done some research on tx/rx in firmware to get software
> encryption in ath10k going, right? Did you play with raw tx format or
> see any obstacles in the code that could prevent it from working?

I never managed to get raw tx mode working with encrypted traffic,
but at least some of those problems might have been some experimental
patches I had in the firmware that were later proved to be broken
(in non-raw tx mode, at least).

In the non-raw (henceforth cooked) mode, the hardware and/or firmware
definitely re-writes the header and will add/remove bits to match
it's idea of what the packet should look like.  It appears impossible
to disable this 'feature' in cooked tx mode.

In my firmware, I did manage to disable the rx decrypt logic so that
I can do sw-crypt.  But, I ended up leaving the transmit path alone
and still using cooked frames and letting the hardware do the packet
encryption and header manipulation.

In my opinion, you will likely require at least firmware source
or someone's help that has access to firmware source to
figure out how to make raw tx mode work if it does not work
immediately for you.

I am busy chasing other firmware issues at the moment, but when I get
that wrapped up (and no idea how long it will take), then I might be able
to at least help get my firmware capable of doing raw tx mode.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QoS Control Field Stripped Off

[Yeoh Chun-Yeow]

> In the non-raw (henceforth cooked) mode, the hardware and/or firmware
> definitely re-writes the header and will add/remove bits to match
> it's idea of what the packet should look like.  It appears impossible
> to disable this 'feature' in cooked tx mode.
I thought that ath10k claims to be a mac80211 driver, so mac80211
pushes the QoS field to the FW. The FW should just honor this, right?

Anyway, I also found out that the broadcast ARP frame generated by the
FW is always non-QoS data frame even though mac80211 specify this as
QoS data frame. Is the FW convert all the group addressed QoS data
frame to non-QoS data frame? Why? I thought that no ACK policy can be
defined in QoS control field for group addressed frame.

> In my opinion, you will likely require at least firmware source
> or someone's help that has access to firmware source to
> figure out how to make raw tx mode work if it does not work
> immediately for you.
Agreed. Who should I talk to?

>
> I am busy chasing other firmware issues at the moment, but when I get
> that wrapped up (and no idea how long it will take), then I might be able
> to at least help get my firmware capable of doing raw tx mode.
>
Thanks for your help. I am looking to get the mesh works in ath10k.

----
Chun-Yeow

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k