search

open-sdr / openwifi

open-source IEEE 802.11 WiFi baseband FPGA (chip) design: driver, software
GNU Affero General Public License v3.0
3.68k stars 627 forks source link

Custom mac80211 module to account for channel delay #330

Open pagmatt opened 11 months ago

pagmatt commented 11 months ago

Hi,

I am using the latest openwifi image (1.4.0) on a Xilinx ZCU102 board. In my experimental setup, the RF front end is connected to a channel emulator which introduces a non-negligible delay to compute the received signal. In turn, this causes the client to deassociate from the AP, since the related timer expires. I am trying to prevent this by loading a custom mac80211 module on the board, unfortunately to no avail. Is my workflow (which I describe below) correct ?

To compile and load the modified module, I follow these steps:

  1. Clone the repository, latest commit (39862403f422c1e3cf15906ec30bab741b427ca9)
  2. Modify the kernel build configuration file kernel_config_zynqmp to build mac80211 and cfg80211 as custom loadable modules: 
    CONFIG_CFG80211=m
CONFIG_MAC80211=m
  3. Introduce my modifications to the mac8022 source files. The cahnges include preventing deassociations, and custom logging messages to double-check that the modules are indeed compiled and loaded correctly (see attached patches, which I apply before building).
  4. Build the kernel source code via prepare_kernel.sh
  5. Transfer the files (cfg80211.ko and mac80211.ko) on the board, and move them to the kernel_modules64 folder
  6. Run the setup_once.sh script to move all the modules to kernel_modules and link them to /lib/modules/5.10.0-98248-g1bbe32fa5182-dirty/
  7. Reboot the board, and start AP and client with wgd.sh and fosdem.sh, respectively. I am attaching the hostapd configuration, which operates on channel 1.

However, the client keeps deassociating, and my custom logs are not printed:

[  618.948416] sdr0: send auth to 66:55:44:33:22:04 (try 1/3)
[  618.948707] sdr0: send auth to 66:55:44:33:22:04 (try 2/3)
[  618.949182] sdr0: send auth to 66:55:44:33:22:04 (try 3/3)
[  618.949511] sdr0: authenticated
[  618.949539] sdr,sdr fpga-axi@0:sdr sdr0: disabling HT/VHT/HE as WMM/QoS is not supported by the AP
[  618.952020] sdr0: associate with 66:55:44:33:22:04 (try 1/3)
[  618.952275] sdr0: associate with 66:55:44:33:22:04 (try 2/3)
[  618.952615] sdr0: associate with 66:55:44:33:22:04 (try 3/3)
[  618.952894] sdr0: RX AssocResp from 66:55:44:33:22:04 (capab=0x401 status=0 aid=1)
[  618.952928] sdr,sdr openwifi_conf_tx: [queue 0], aifs: 2, cw_min: 3, cw_max: 7, txop: 47, aifs and txop ignored
[  618.952934] sdr,sdr openwifi_conf_tx: [queue 1], aifs: 2, cw_min: 7, cw_max: 15, txop: 94, aifs and txop ignored
[  618.952939] sdr,sdr openwifi_conf_tx: [queue 2], aifs: 3, cw_min: 15, cw_max: 1023, txop: 0, aifs and txop ignored
[  618.952944] sdr,sdr openwifi_conf_tx: [queue 3], aifs: 7, cw_min: 15, cw_max: 1023, txop: 0, aifs and txop ignored
[  618.952950] sdr,sdr openwifi_bss_info_changed WARNING BSS_CHANGED_ERP_SLOT 8 BSS_CHANGED_ERP_PREAMBLE 0 short slot 1
[  618.952964] sdr0: associated
[  618.953022] IPv6: ADDRCONF(NETDEV_CHANGE): sdr0: link becomes ready
[  618.953167] sdr,sdr openwifi_prepare_multicast
[  618.953175] sdr,sdr openwifi_configure_filter MON 0 M_BCN 1 BST0 1 BST1 1 UST 1 PB_RQ 0 PS_PL 1 O_BSS 0 CTL 0 BCN_PRP 0 PCP_FL 0 FCS_FL 0 ALL_MUT 1
[  618.964572] sdr0: disassociated from 66:55:44:33:22:04 (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)
[  619.004138] sdr,sdr openwifi_bss_info_changed BSS_CHANGED_BSSID 000000000000

custom_deassoc_msg patch no_deassoc patch hostapd-openwifi.conf

HavingaThijs commented 11 months ago

After running prepare_kernel.sh, did you copy the the generated adi-linux-64/arch/arm64/boot/Image file to the base directory of the BOOT partition on the SD card? Recently I applied a patch to mac80211 directly without loading it as a custom module, which did work by just recompiling the kernel and using the new image.

JiaoXianjun commented 10 months ago

Try this:

https://github.com/open-sdr/openwifi/issues/334#issuecomment-1676886785