Timestamp

[kebZhang]

Hi
I have encountered a problem about timestamp. I use one openwifi(antsdr E310) to serve as AP，another openwifi(antsdr E310) to serve as client. I write a simple socket communication between AP and client to communicate some information and at the same time, I get CSI from the client board.
I found that the timestamp showed in side_info_display.py result is the tsf time of CSI.

And I want to align one CSI to the corresponding packet.
I use tcpdump -i sdr0 to sniffer the packet. And I saw that below. The ip address of AP is 192.168.13.1, the ip address of client is 192.168.13.12.

The time before IP is the system time because when I running 'date' in the shell of ubuntu, the time is the same.
Could you please help me to explain how to align one CSI to the corresponding packet?

[JiaoXianjun]

the tsf time of CSI should be from this code in driver:

openwifi/driver/sdr.c

Line 530 in 0ce2e6b

rx_status.mactime = ( ( (u64)tsft_low ) | ( ((u64)tsft_high)<<32 ) );

tsft_low and tsft_high are from FPGA tsf counter value (brought by the packet captured).

Maybe you should set tsft_low and tsft_high (in total 64bit value with unit microsecond) by your system time (you could convert it to 64bit value in microsecond) by sdrctl command via this piece of code in driver:

https://github.com/open-sdr/openwifi/blob/0ce2e6b86ade2f6164a373b2e98d075eb7eecd9e/driver/sdrctl_intf.c#L218C15-L218C15

The command: https://github.com/open-sdr/openwifi/blob/master/doc/README.md#get-and-set-a-parameter

Other possible way is read/write the tsf counter register. Search "module_name: xpu" in https://github.com/open-sdr/openwifi/blob/master/doc/README.md#get-and-set-a-register-of-a-module . reg_idx 2 and 3.

[kebZhang]

Thank you for your help. I have look through sdr.c. I found that after receiving a packet from the air, FPGA will raise interrupt (if the frame filtering rule allows) to Linux, then the function openwifi_rx_interrupt() of openwifi driver (sdr.c) will be triggered. In that function, ieee80211_rx_irqsafe() API is used to give the packet and related information (timestamp, rssi, etc) to upper layer.

First, I tried to change the code in openwifi_rx_interrupt() to set the rx_status.mactime the same as the system time.

But after I compile the driver and try to get csi in monitor mode, the timestamp which printed by side_info_display.py is different from the linux system time. I think my change have not worked.

Then, I have tried to change code in function openwifi_start(struct ieee80211_hw *dev) to change the initial tsf the same as linux system time.

But I have found that, when I compile the driver and get csi in monitor mode, the timestamp printed by side_info_display.py is different from linux system time.
I think there maybe something I don't understand well when the tsf is given to upper layer. Cause when I set the tsf_time in openwifi_start(), I printk in openwifi_rx_interrupt() to see the rx_status.mactime, mactime is the same as linux system.

Could you please give me some help?

[JiaoXianjun]

What you did is not what I said in my reply. You need to try what I said.

[JiaoXianjun]

If you capture packet via:

iw dev sdr0 interface add mon0 type monitor && ifconfig mon0 up
tcpdump -i mon0 -s 65535 -w openwifi.pcap

The 1st command creates an monitor interface mon0. The 2nd command captures packets into a file: openwifi.pcap.
Then open the openwifi.pcap by wireshark, you will find the TSF time of each packet.

To monitor only the incoming packet from the air (exclude the packets outcoming from the board), you can use

tcpdump -i mon0 ether dst 66:55:44:33:22:60 -s 65535 -w openwifi.pcap

Remember to change 66:55:44:33:22:60 to MAC address of your openwifi NIC sdr0 .

[kebZhang]

I have tried what you said, and I have found the tsf time in wireshark. I'm still trying to align the tsf time and csi information of the same packet.

[JiaoXianjun]

I have tried what you said, and I have found the tsf time in wireshark. I'm still trying to align the tsf time and csi information of the same packet.

Please check this discussion:

#344