Is auto acknowledgements enabled in monitor mode? about openwifi HOT 8 CLOSED

Hello,

The ACK and re-transmission state machine is in FPGA xpu (tx_control.v). Regarding ACK, there are two things:

1. After FPGA transmits a packet, wait for ACK. If ACK is received in time, report to ARM --> Linux. If ACK is not received in time, do re-transmission according to the packet re-transmission configuration, and report finally to ARM --> Linux (how many times re-transmission is tried, etc)

Above behavior is configured per packet in driver (sdr.c, openwifi_tx() ):

dma_reg = ( (( ((prio<<(NUM_BIT_MAX_NUM_HW_QUEUE+NUM_BIT_MAX_PHY_TX_SN))|(ring->bd_wr_idx<<NUM_BIT_MAX_NUM_HW_QUEUE)|queue_idx) )<<18)|(retry_limit_hw_value<<14)|(pkt_need_ack<<13)|num_dma_symbol );

If pkt_need_ack is 0, FPGA won't wait for ACK and return immediately without any re-transmission (tx_control.v):

RECV_ACK_JUDGE: begin
// ack_tx_flag<=ack_tx_flag;
// wea<=wea;
// dina<=dina;
// send_ack_count <= send_ack_count;
// ack_addr <= ack_addr;
// ack_timeout_count<=ack_timeout_count;
// start_retrans<=start_retrans;
// tx_dpram_op_counter<=tx_dpram_op_counter;
// douta_reg<=douta_reg;
// recv_ack_timeout_top<=recv_ack_timeout_top;
retrans_started<=0;
if (tx_pkt_need_ack==1) // continue to actual ACK receiving
    begin
    tx_control_state<= RECV_ACK_WAIT_TX_BB_DONE;
    addra<=2;
    tx_try_complete<=0;
    // tx_status<=tx_status; //maintain status from state RECV_ACK for ARM reading
    // num_retrans<=num_retrans;
    retrans_in_progress<=1;
    end
else
    begin
    tx_control_state<= IDLE;
...

retry_limit_hw_value controls the maximum number of re-transmission.
You need to check these two parameters (pkt_need_ack, retry_limit_hw_value) in your mode (monitor mode) when sdr.c is running, to foresee the FPGA behavior.

2. After FPGA receives a packet, FPGA will send back ACK according to the packet type and CRC result. In tx_control.v:

if ( fcs_valid && (is_data||is_management||is_blockackreq||is_blockack||is_pspoll||(is_rts&&(!cts_torts_disable))) 
               && (self_mac_addr==addr1)) // send ACK will not back to this IDLE until the last IQ sample sent.
  begin
      tx_control_state  <= SEND_ACK; //we also send cts (if rts is received) in SEND_ACK status
  end

Indeed this part is not affected by the monitor mode currently, so even in monitor mode FPGA still sends ACK for the incoming packet (if the condition is met).

In all the ACK related processing (if happens), the target MAC address is checked/set.

I guess the automatic ACK sent by FPGA is very useful for fuzzing work, because purely relying on your packet injection in monitor mode can not make ACK in time (16 or 10us). I don't know whether other COTS WiFi card does similar auto ACK like us in the monitor mode.

Or,

Should we disable the FPGA auto sending ACK in monitor mode? Or add a switch (register) to give user more control from driver/strctl? If you could elaborate more about your use case and consideration, we can do the implementation (shouldn't be heavy I think).

from openwifi.

If no further question, I will close this issue.

from openwifi.

Hi @JiaoXianjun thanks a lot for your detailed answer. Actually, for my application auto acknowledgment responses during monitor mode is already what we want. Generally, commercial Wi-Fi hardware disables auto acknowledgments in monitor mode under Linux and we need to enable it by setting a hardware register bit, so OpenWi-FI already has this enabled by default.

However, I see that to maintain behavior compatibility with Linux, adding an ack register so we can disable or enable this behavior would be ideal since in monitor mode we may want to be as transparent as possible and not auto-reply nor auto-retry when injecting packets.

Regards.

from openwifi.

To disable (or confirm it is already the case from Linux config per packet) “waiting for ack and auto retry”, you can set (or print) pkt_need_ack and retry_limit_hw_value to 0 in driver.

To disable “auto reply ack” in monitor mode, we will add a register for user to control.

from openwifi.

Thanks a lot, @JiaoXianjun . And once again, thanks a lot for this great project. I'm going to close the issue and would suggest that the information of auto acknowledgments may be added to the monitor mode documentation so people know of these side effects when running OpenWi-Fi in monitor mode.

from openwifi.

Hello,

We have lots of update just now in driver and FPGA. Two are related to the WiFi fuzzing:

• the ACK disable register is added.
• a bug of retransmission when packet is injected under monitor mode is fixed.
  • According to the comments on "struct ieee80211_tx_rate" in mac80211.h, mac80211 should tell driver that the packet should be transmitted "up to" how many times. However when packet is injected under monitor mode, this "up to" number is 0, which is abnormal/make-no-sense. In this case our original code uses 15 instead of 0. Now the code uses 1 instead of 0. You can also override it.

See more explanations: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/inject_80211.md

You can use the latest SD card image directly or pull the latest driver/FPGA.

from openwifi.

@JiaoXianjun thanks a lot, I've also seen the updated documentation and this will definitely suit our use.

from openwifi.

Hi @JiaoXianjun thanks a lot for your detailed answer. Actually, for my application auto acknowledgment responses during monitor mode is already what we want. Generally, commercial Wi-Fi hardware disables auto acknowledgments in monitor mode under Linux and we need to enable it by setting a hardware register bit, so OpenWi-FI already has this enabled by default.

However, I see that to maintain behavior compatibility with Linux, adding an ack register so we can disable or enable this behavior would be ideal since in monitor mode we may want to be as transparent as possible and not auto-reply nor auto-retry when injecting packets.

Regards.

Hello, just curious, would you please tell us about which COTS WiFi support the auto ACK in monitor mode? (by the register setting as you mentioned)

Thanks!

from openwifi.