Could you send email to xianjun.jiao@ugent.be to introduce your self?
Previously sent one.
Our image is used directly or you build your own image?
Your latest image.
What is your own modification?
NA
Versions: OS, Vivado, openwifi/openwifi-hw repo branch and commit revision
Board/hardware type
adrv9361z7035
WiFi channel number
6 (Same behavior in other channels)
Steps to reproduce the issue, and the related error message, screenshot, etc
While in monitor mode the openwifi device seems to be not able to correctly transmit certain payload depending on the WiFi standard being used.
Put an RF SOM into monitor mode.
./wgd.sh
./monitor_ch.sh sdr0 6
Put a laptop into monitor mode using channel 6.
Open wireshark on the wireless interface and use a filter of "wlan.sa == 66:55:44:33:22:33" to only observe the packets coming from the RF SOM.
Replace the inject_80211.c file with the file attached. Compile inject_80211 by performing. "make clean; make".
The new inject_80211.c file contains four payloads which can be utilized by using an option -p <payload_number> while running inject_80211 program.
Payload number 1: Contains a payload which does not work with 802.11a but works with 802.11n.
Payload number 2: Contains a slightly changed payload which works with 802.11a. In this case 0x64, 0x3a, 0x06, 0xe9, 0x88, from payload 1 is changed to 0x64, 0x3b, 0x06, 0xe9, 0x88, with just a single byte change.
Payload number 3: Contains a payload which does not work with 802.11n but works with 802.11a.
Payload number 4: Contains a slightly changed payload which works with 802.11n. In this case 0x50, 0x6f, 0xd6, 0x24, 0xef, from payload 3 is changed to 0x50, 0x66, 0xd6, 0x24, 0xef, with just a single byte change.
Run inject_80211 with different options and observe the reception with wireshark on your laptop.
Experiments and observations:
Case
Standard
Payload #
Command
Observation
1
802.11a
1
./inject_80211 -m a -r 0 -t d -p 1 -e 8 -d 10000 -n 1000 sdr0
Packet is not seen in wireshark.
2
802.11a
2
./inject_80211 -m a -r 0 -t d -p 2 -e 8 -d 10000 -n 1000 sdr0
Packet is seen in wireshark.
3
802.11n
1
./inject_80211 -m n -r 0 -t d -p 1 -e 8 -d 10000 -n 1000 sdr0
Packet is seen in wireshark.
4
802.11n
3
./inject_80211 -m n -r 0 -t d -p 3 -e 8 -d 10000 -n 1000 sdr0
Packet is not seen in wireshark.
3
802.11n
4
./inject_80211 -m n -r 0 -t d -p 4 -e 8 -d 10000 -n 1000 sdr0
Packet is seen in wireshark.
3
802.11a
3
./inject_80211 -m n -r 0 -t d -p 3 -e 8 -d 10000 -n 1000 sdr0
Packet is seen in wireshark.
In the failure cases, we observe that for case 1 0x3a, 0x06, 0xe9, is randomly changed and for case 4 0x6f, 0xd6, 0x24, is randomly changed.
Describe your debug efforts by Linux native tools, such as tcpdump and "cat /proc/interrupts"
Futher testing with another RF SOM revealed that for Case 1 and 4, the packets are received but they are marked as Bad FCS. On the laptop, the wireless interface directly rejects the Bad FCS packet hence they are not seen on the wireshark.
The same experiments can be performed on a laptop using its Wireless interface in monitor mode. Here, in all the cases all packets are correctly received on RF SOM and on another laptop's wireless interface.
This leads me to believe that the reception on openwifi works well with any kind of standard but the transmission has problem with certain payload and wireless standard combination.
Any other thing we need to know for helping you better?
I believe, the problem lies maybe in openofdm_tx. As we observe bad FCS issue, this implies that once the FCS is generated at the transmitter and added to the payload. The receiver always finds changed payload which causes the FCS mismatch issue. Since, we already observed that the same packets from a laptop are correctly received with openwifi's RX therefore the problem must be at openwifi's TX.
Please let me know if you have any problems reproducing the issue.
inject_80211.c.txt
Could you send email to xianjun.jiao@ugent.be to introduce your self? Previously sent one.
Our image is used directly or you build your own image? Your latest image.
What is your own modification? NA
Versions: OS, Vivado, openwifi/openwifi-hw repo branch and commit revision
Board/hardware type adrv9361z7035
WiFi channel number 6 (Same behavior in other channels)
Steps to reproduce the issue, and the related error message, screenshot, etc While in monitor mode the openwifi device seems to be not able to correctly transmit certain payload depending on the WiFi standard being used.
-p <payload_number>while running inject_80211 program. Payload number 1: Contains a payload which does not work with 802.11a but works with 802.11n. Payload number 2: Contains a slightly changed payload which works with 802.11a. In this case0x64, 0x3a, 0x06, 0xe9, 0x88,from payload 1 is changed to0x64, 0x3b, 0x06, 0xe9, 0x88,with just a single byte change. Payload number 3: Contains a payload which does not work with 802.11n but works with 802.11a. Payload number 4: Contains a slightly changed payload which works with 802.11n. In this case0x50, 0x6f, 0xd6, 0x24, 0xef,from payload 3 is changed to0x50, 0x66, 0xd6, 0x24, 0xef,with just a single byte change.Experiments and observations:
./inject_80211 -m a -r 0 -t d -p 1 -e 8 -d 10000 -n 1000 sdr0./inject_80211 -m a -r 0 -t d -p 2 -e 8 -d 10000 -n 1000 sdr0./inject_80211 -m n -r 0 -t d -p 1 -e 8 -d 10000 -n 1000 sdr0./inject_80211 -m n -r 0 -t d -p 3 -e 8 -d 10000 -n 1000 sdr0./inject_80211 -m n -r 0 -t d -p 4 -e 8 -d 10000 -n 1000 sdr0./inject_80211 -m n -r 0 -t d -p 3 -e 8 -d 10000 -n 1000 sdr0In the failure cases, we observe that for case 1
0x3a, 0x06, 0xe9,is randomly changed and for case 40x6f, 0xd6, 0x24,is randomly changed.Describe your debug efforts by Linux native tools, such as tcpdump and "cat /proc/interrupts"
Describe your debug efforts by: https://github.com/open-sdr/openwifi/blob/master/doc/README.md#Debug-methods
Any other thing we need to know for helping you better? I believe, the problem lies maybe in openofdm_tx. As we observe bad FCS issue, this implies that once the FCS is generated at the transmitter and added to the payload. The receiver always finds changed payload which causes the FCS mismatch issue. Since, we already observed that the same packets from a laptop are correctly received with openwifi's RX therefore the problem must be at openwifi's TX.
Please let me know if you have any problems reproducing the issue. inject_80211.c.txt