How to make openwifi work in 802.11b mode and the phone can successfully connect to the hotspot

[jylccc]

0. Could you send email to xianjun.jiao@ugent.be to introduce your self?
   yes,i already send it to you
1. Our image is used directly or you build your own image?
   use your image
2. What is your own modification?
   Try to change the working mode of openwifi to 802.11b.
3. Versions: OS, Vivado, openwifi/openwifi-hw repo branch and commit revision
   unbuntu18.3
   vivado2018.3
   openwifi branch :master
   commit revision：2021.04
4. Board/hardware type
   zedboard+fcommcs3
5. WiFi channel number
   6
6. Steps to reproduce the issue, and the related error message, screenshot, etc
   I want to make openwifi work in 802.11b mode, I refer to the special note for 11b you wrote, I may not understand the meaning, I first changed the support_rate and base_rate in hostapd-openwifi-11ag：

interface=sdr0
driver=nl80211
country_code=BE
ssid=openwifi
hw_mode=g
channel=6
#supported_rates=2 4 11 22
#basic_rates=2 4
#supported_rates=60 90 120 180 240 360 480 540
#basic_rates=60 90 120 180
supported_rates=10 20 55 110
basic_rates=10 20 55 110
#supported_rates=60 90
#basic_rates=60 90
#ieee80211n=1
#ht_capab=[SHORT-GI-20]
#require_ht=1
#ieee80211d=1
#ieee80211h=1
#wpa=2
#wpa_passphrase=myrabbit
#wpa_key_mgmt=WPA-PSK

After logging into my zedboard with putty, I executed the following command at end point

cd openwifi
./fosedem-11ag.sh
./build_wpa_supplicant_wo11b.sh
./fosdem.sh contains:

#!/bin/bash
# Author: Xianjun Jiao
# SPDX-FileCopyrightText: 2019 UGent
# SPDX-License-Identifier: AGPL-3.0-or-later

killall hostapd
killall webfsd

cd ~/openwifi
service network-manager stop
./wgd.sh
ifconfig sdr0 192.168.13.1
route add default gw 192.168.10.1
service isc-dhcp-server restart
hostapd hostapd-openwifi-11ag.conf &
sleep 5
cd webserver
webfsd -F -p 80 -f index.html &

build_wpa_supplicant_wo11b.sh contains:

#!/bin/bash

# Author: Michael Mehari
# SPDX-FileCopyrightText: 2019 UGent
# SPDX-License-Identifier: AGPL-3.0-or-later

#if [ "$#" -ne 1 ]; then
#    echo "You must enter exactly 1 arguments: \$OPENWIFI_DIR"
#    exit 1
#fi

#OPENWIFI_DIR=$1

set -x

#cd $OPENWIFI_DIR/user_space
wget http://w1.fi/releases/wpa_supplicant-2.1.tar.gz
tar xzvf wpa_supplicant-2.1.tar.gz
patch -d wpa_supplicant-2.1/src/drivers/ < driver_nl80211.patch
cd wpa_supplicant-2.1/wpa_supplicant/
cp defconfig .config
sed -i 's/#CONFIG_LIBNL32.*/CONFIG_LIBNL32=y/g' .config
make clean
make -j16
# sudo make install
cd ../../
rm -r wpa_supplicant-2.1/ wpa_supplicant-2.1.tar.gz

The final result is that the wifi signal can be detected on the mobile phone, but when connected, the network refuses the request.
7. Describe your debug efforts by Linux native tools, such as tcpdump and "cat /proc/interrupts"

8. Describe your debug efforts by: https://github.com/open-sdr/openwifi/blob/master/doc/README.md#Debug-methods

9. Any other thing we need to know for helping you better?

[HavingaThijs]

Unfortunately IEEE 802.11b is not supported by openwifi. Since it's based on DSSS modulation instead of OFDM, it would require a significant amount of work to support it.
The special note is for the device connecting to openwifi; it should disable using 802.11b for any frames in order for openwifi to be able to receive it.

[jylccc]

Unfortunately IEEE 802.11b is not supported by openwifi. Since it's based on DSSS modulation instead of OFDM, it would require a significant amount of work to support it. The special note is for the device connecting to openwifi; it should disable using 802.11b for any frames in order for openwifi to be able to receive it.
First of all, thank you very much for your reply. If I want to add an 802.11b mode at the physical layer and then start an 802.11 process at the upper layer of the original architecture, and make the physical layer interface and MAC layer data interaction of the newly added 802.11b imitate those of 802.11a/g/n, is this feasible? Also, in which files are the processes and interfaces used for the interaction between the physical layer and MAC layer of 802.11a/g/n specifically located? And can the reception of 802.11b share the reception process of 802.11a/g/n? Do I just need to add 802.11b in the decode part?Looking forward to your reply.

[HavingaThijs]

Since 802.11b is based on DSSS and not OFDM, you'll have to modify the whole receiver chain running on the FPGA, whose top-level state machine is currently implemented here. In principle I believe the MAC layer can remain the same, so indeed you just need to add the decoding of 802.11b, but as this is a whole new PHY (e.g. even packet detection is different) this will require quite some work.

[jylccc]

Thank you very much for your reply. If I were to implement another 802.11b and get it running successfully, it would be too difficult for one person. Could I hire you or your team to help me complete this work for a fee?

…

---Original--- From: "Thijs ***@***.***> Date: Mon, Apr 14, 2025 22:43 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [open-sdr/openwifi] How to make openwifi work in 802.11b mode andthe phone can successfully connect to the hotspot (Issue #454) Since 802.11b is based on DSSS and not OFDM, you'll have to modify the whole receiver chain running on the FPGA, whose top-level state machine is currently implemented here. In principle I believe the MAC layer can remain the same, so indeed you just need to add the decoding of 802.11b, but as this is a whole new PHY (e.g. even packet detection is different) this will require quite some work. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***> HavingaThijs left a comment (open-sdr/openwifi#454) Since 802.11b is based on DSSS and not OFDM, you'll have to modify the whole receiver chain running on the FPGA, whose top-level state machine is currently implemented here. In principle I believe the MAC layer can remain the same, so indeed you just need to add the decoding of 802.11b, but as this is a whole new PHY (e.g. even packet detection is different) this will require quite some work. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[HavingaThijs]

802.11b support is currently not in our roadmap, for requests regarding business collaboration please contact Filip.Louagie@UGent.be.

[ViruKM]

Hi Thijis,
I am trying build FPGA for Openwifi-hw for antsde200 board. i followed all the steps given in readme. but i am facing lot of errors and i am unable to do ./openwifi.tcl file in vivado and its open openofdm block.

[jylccc]

802.11b support is currently not in our roadmap, for requests regarding business collaboration please contact Filip.Louagie@UGent.be.

Thank you very much for your reply. If I want to capture the WiFi received signal level, frequency offset, carrier-to-noise ratio, bit error rate, carrier lock indication, JT lock indication, etc. on the PC side, how can I find these values? Are there clear definitions in the baseband part? The dot11tx.txt file generated by the transmitter and the samples.dat file directly used by the receiver are not the same. The format of the corresponding samples.txt file generated by Python is also different from that of dot11tx.txt. How should I handle it if I want to calculate the bit error rate?

[HavingaThijs]

You need several different ways to obtain these different values, e.g. this application note for the frequency offset when capturing real Wi-Fi packets.
Bit error rate is not automatically calculated, you would need to compare the decoded bits with the known bits.
"Carrier lock" is e.g. the "short preamble detected" counter: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/perf_counter.md

I'm not entirely sure where you are referring to with the samples.dat file and samples.txt file.

[jylccc]

您需要几种不同的方法来获取这些不同的值，例如，此应用说明用于捕获实际 Wi-Fi 数据包时的频率偏移。误码率不是自动计算的，您需要将解码后的位与已知位进行比较。 例如，“Carrier lock” 是 “short preamble detected” 计数器：https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/perf_counter.md

我不完全确定你指的是 file 和 file 的什么地方。samples.dat``samples.txt

OK, thanks. But where can I find the JT lock and receive level indication? Currently, does OpenWiFi support 2x2 MIMO? If it does, are there any test metrics or test plans for 2x2 MIMO introduced in the MD document?

[jylccc]

You need several different ways to obtain these different values, e.g. this application note for the frequency offset when capturing real Wi-Fi packets. Bit error rate is not automatically calculated, you would need to compare the decoded bits with the known bits. "Carrier lock" is e.g. the "short preamble detected" counter: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/perf_counter.md

I'm not entirely sure where you are referring to with the samples.dat file and samples.txt file.

Hello, I would like to ask you a question, that is, I want to make n work at 2.4Ghz, change hw_mode to g,channel set to 6, other things remain the same, but openwifi network does not show up, my code screenshot is as follows.
hostapd-openwifi.conf contains：
interface=sdr0 driver=nl80211 country_code=BE ssid=openwifi hw_mode=g channel=6 supported_rates=60 90 120 180 240 360 480 540 basic_rates=60 90 120 180 ieee80211n=1 #ht_capab=[SHORT-GI-20] require_ht=1 #ieee80211d=1 #ieee80211h=1 #wpa=2 #wpa_passphrase=myrabbit #wpa_key_mgmt=WPA-PSK
fosdem.sh contains:
`killall hostapd
killall webfsd

cd ~/openwifi
service network-manager stop
./wgd.sh
ifconfig sdr0 192.168.13.1
route add default gw 192.168.10.1
service isc-dhcp-server restart
hostapd hostapd-openwifi.conf &
sleep 5
cd webserver
webfsd -F -p 80 -f index.html &
`
terminal contains:

sdr0: STA 9e:86:dc:ad:87:cc IEEE 802.11: associated (aid 1)
sdr0: AP-STA-CONNECTED 9e:86:dc:ad:87:cc
sdr0: STA 9e:86:dc:ad:87:cc RADIUS: starting accounting session 0000002E-00000000
sdr0: STA 9e:86:dc:ad:87:cc IEEE 802.11: authenticated
sdr0: STA 9e:86:dc:ad:87:cc IEEE 802.11: did not acknowledge authentication response
sdr0: STA 9e:86:dc:ad:87:cc IEEE 802.11: did not acknowledge authentication response
sdr0: STA 9e:86:dc:ad:87:cc IEEE 802.11: did not acknowledge authentication response
sdr0: STA 9e:86:dc:ad:87:cc IEEE 802.11: did not acknowledge authentication response

[jylccc]

You need several different ways to obtain these different values, e.g. this application note for the frequency offset when capturing real Wi-Fi packets. Bit error rate is not automatically calculated, you would need to compare the decoded bits with the known bits. "Carrier lock" is e.g. the "short preamble detected" counter: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/perf_counter.md

I'm not entirely sure where you are referring to with the samples.dat file and samples.txt file.

When I use OFDMDecoder for decoding, I find that it can accept at most 4095 bytes. legacy_len is a 12-bit type. If I want to decode 1e7 bits, what should I do? I'm looking forward to your reply very much.

[HavingaThijs]

The 12 bits come from the IEEE 802.11 standard. If you need to modify that, it won't be compliant anymore.
However, decoding 1e7 bits in one packet will in reality be very difficult, e.g. because of the channel and carrier frequency offset (resulting in a phase offset) that will change over time. I would advise splitting it up into multiple packets.

[jylccc]

The 12 bits come from the IEEE 802.11 standard. If you need to modify that, it won't be compliant anymore. However, decoding 1e7 bits in one packet will in reality be very difficult, e.g. because of the channel and carrier frequency offset (resulting in a phase offset) that will change over time. I would advise splitting it up into multiple packets.

Thank you very much for your reply. The sub-packet sending is effective, but the decoding speed is too slow. I am decoding it in Python using iverilog based on the code in the openofdm repository. Does this affect the speed? I also have a confusion: how to capture the actual IQ data at a specified rate/MCS. The document iq.md mentions capturing IQ, and I also saw the rate configuration under TX rate config. But I don't know how to combine these two operation instructions. If I can log in to the board to control the rate, can I connect my phone to the openwifi network and then capture the actual IQ? When I operate according to the commands in iq.md, I cannot connect to openwifi. The above are some of my experiences. Could you please tell me how to correctly capture the actual IQ (not the physical layer IQ data)? I am looking forward to your reply.

[HavingaThijs]

I am decoding it in Python using iverilog based on the code in the openofdm repository. Does this affect the speed?

Decoding in simulation on a CPU will always be slow as it needs to emulate the logic on the FPGA. Decoding more bits in one packet will not help much with this.

If I can log in to the board to control the rate, can I connect my phone to the openwifi network and then capture the actual IQ? When I operate according to the commands in iq.md, I cannot connect to openwifi.

Yes, follow the instructions to capture the IQ using the application note, but instead of ./monitor_ch.sh sdr0 11 you use ./fosdem.sh (starting as access point instead of monitoring). Then set the rate with drv_tx register 0 and 1.

Could you please tell me how to correctly capture the actual IQ (not the physical layer IQ data)

I'm not sure what you mean with "actual IQ". The IQ here refers to the physical layer IQ data.

[jylccc]

I am decoding it in Python using iverilog based on the code in the openofdm repository. Does this affect the speed?

Decoding in simulation on a CPU will always be slow as it needs to emulate the logic on the FPGA. Decoding more bits in one packet will not help much with this.

If I can log in to the board to control the rate, can I connect my phone to the openwifi network and then capture the actual IQ? When I operate according to the commands in iq.md, I cannot connect to openwifi.

Yes, follow the instructions to capture the IQ using the application note, but instead of ./monitor_ch.sh sdr0 11 you use ./fosdem.sh (starting as access point instead of monitoring). Then set the rate with drv_tx register 0 and 1.

Could you please tell me how to correctly capture the actual IQ (not the physical layer IQ data)

I'm not sure what you mean with "actual IQ". The IQ here refers to the physical layer IQ data.

Sorry, it should be the IQ data of the physical layer. When I tried to connect my Zed development board to capture the IQ data on iq_capture.py and then send it to the openOFDM decoder for decoding, it got stuck in the Power triggered state all the time. Is there something wrong with my operation of capturing the IQ data or is it due to other reasons? Looking forward to your reply.
cd openwifi
./fosdem-11ag.sh
insmod side_ch.ko iq_len_init=4095
./sdrctl dev sdr0 set reg drv_tx 0 8
./side_ch_ctl wh11d4094
./side_ch_ctl wh8d0
./side_ch_ctl wh5d1
./side_ch_ctl g
I followed the above steps, connected to OpenWiFi and worked in 802.11a mode, then python3 iq_capture.py start to capture iq data