seemoo-lab / mobisys2018_nexmon_channel_state_information_extractor

Example project for extracting channel state information of up to 80 MHz wide 802.11ac Wi-Fi transmissions using the BCM4339 Wi-Fi chip of Nexus 5 smartphones.
Other
98 stars 39 forks source link

Capture data frame #2

Open y-x-c opened 6 years ago

y-x-c commented 6 years ago

Now I can capture and parse CSI data on beacon frame(frame control field 0x8000) and block ack frame(0x9400). However I am not able to capture data frame (0x8842 or QoS Data) which can be captured on another phone with default firmware, I just captured nothing when I ran tcpdump. Is this an expected behavior for the CSI extractor? Thanks.

matthiasseemoo commented 6 years ago

Try to first capture the data in monitor mode. The nexus 5 has only one antenna, so it can only capture single stream transmissions. Additionally, the bandwidth of your receiver should be set accordingly to receive your data frames.

Yuxin Chen notifications@github.com schrieb am Mo., 2. Apr. 2018, 05:56:

Now I can capture and parse CSI data on beacon frame(frame control field 0x8000) and block ack frame(0x9400). However I am not able to capture data frame (0x8842 or QoS Data), I just captured nothing when I ran tcpdump. Is this an expected behavior for the CSI extractor? Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7ns7nzHvPF2au8Ch5vhBocuRuuc1ks5tkaFigaJpZM4TDHtd .

y-x-c commented 6 years ago

Thanks for your quick response. I did some more experiments today:

I watched a youtube live video and captured data in monitor mode (by running nexutil -m2). I found:

For CSI mode, I am still not able to capture data frame in both 2.4G and 5G band.

Another finding is that if I capture CSI in 2.4G band after I capture CSI in 5G band, then I will get nothing.

I am also confused about the chanspec in filter string. What I understand now is the first two hex digits stand for channel, but I am not sure how to parse the last two digits.

In addition, can I capture CSI without filtering (i.e. capture packets of all types)?

matthiasseemoo commented 6 years ago

Take a look at the channels.h file. Keep in mind that after extracting the CSI the frame cannot be received correctly anymore. So you should only get the CSI but no valid data frames.

On Mon, Apr 2, 2018 at 9:35 PM, Yuxin Chen notifications@github.com wrote:

Thanks for your quick response. I did some more experiments today:

I watched a youtube live video and captured data in monitor mode (by running nexutil -m2). I found:

  • in 5G band (802.11n, channel 40, 20Mhz), I still can not capture data frames between my laptop and the AP.
  • in 2.4G band (802.11n, 20Mhz), I can capture all the data frames.

For CSI mode, I am still not able to capture data frame in both 2.4G and 5G band.

Another finding is that if I capture CSI in 2.4G band after I capture CSI in 5G band, then I will get nothing.

I am also confused about the chanspec in filter string. What I understand now is the first two hex digits stand for channel, but I am not sure how to parse the last two digits.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-378020639, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7ufqU5kmf_b5991h7GPyRzdL8hJWks5tkn1-gaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

y-x-c commented 6 years ago

I didn't get even CSI for some frame. The only stable working case for me is capturing CSI of beacon in 5Ghz. For 2.4Ghz, I can only capture original beacon packet, but the CSI is not reported. For BlockACK, I previously captured CSI successfully, but now I can not reproduce the result anymore. For data frame, neither CSI nor original frame is captured.

matthiasseemoo commented 6 years ago

Do you see any error messages when you execute dhdutil consoledump. You should try to run your expwriments in a controlled environment. Use an empty channel and inject frames one by one and see if that works for you.

Yuxin Chen notifications@github.com schrieb am Mi., 4. Apr. 2018, 20:19:

I didn't get even CSI for some frame. The only stable working case for me is capturing CSI of beacon in 5Ghz. For 2.4Ghz, I can only capture original beacon packet, but the CSI is not reported. For BlockACK, I previously captured CSI successfully, but now I can not reproduce the result anymore. For data frame, neither CSI nor original frame is captured.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-378696702, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7gTXkqKJcsDj0Wya4opfNpcmx5mFks5tlQ6mgaJpZM4TDHtd .

matthiasseemoo commented 6 years ago

And use only single stream transmissions as the nexus 5 has only one antenna.

Matthias Schulz mschulz@seemoo.tu-darmstadt.de schrieb am Mi., 4. Apr. 2018, 21:15:

Do you see any error messages when you execute dhdutil consoledump. You should try to run your expwriments in a controlled environment. Use an empty channel and inject frames one by one and see if that works for you.

Yuxin Chen notifications@github.com schrieb am Mi., 4. Apr. 2018, 20:19:

I didn't get even CSI for some frame. The only stable working case for me is capturing CSI of beacon in 5Ghz. For 2.4Ghz, I can only capture original beacon packet, but the CSI is not reported. For BlockACK, I previously captured CSI successfully, but now I can not reproduce the result anymore. For data frame, neither CSI nor original frame is captured.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-378696702, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7gTXkqKJcsDj0Wya4opfNpcmx5mFks5tlQ6mgaJpZM4TDHtd .

y-x-c commented 6 years ago

I will try to run the experiments in a controlled environment. I did use single stream transmissions.

This is the result of dhdutil consoledump:

start=0x001eb5d8 len=0x00000800

RTE (USB-SDIO-CDC) 6.37.32.RC23.34.43 (r639704) on BCM4339 r1 @ 37.4/161.3/161.3MHz
000000.010 sdpcmdcdc0: Broadcom SDPCMD CDC driver
000000.142 reclaim section 0: Returned 31688 bytes to the heap
000000.191 wl0: Broadcom BCM4339 802.11 Wireless Controller 6.37.32.RC23.34.43 (r639704)
000000.198 wl_nd_ra_filter_init: Enter..
000000.202 TCAM: 256 used: 198 exceed:0
000000.206 reclaim section 1: Returned 71844 bytes to the heap
000000.212 sdpcmd_dpc: Enable
000000.220 wl0: wlc_bmac_ucodembss_hwcap: Insuff mem for MBSS: templ memblks 192 fifo memblks 259
000000.234 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
000000.281 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
000000.289 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
000067.947 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
000067.954 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
y-x-c commented 6 years ago

About the chanspec: if I want to capture on channel 2, then chanspec should be 0210, right?

matthiasseemoo commented 6 years ago

If you are on the chip use the macros from channels.h to build the chanspec. If you want to set the channel in Android, nexutil -k2 should do it. Keep in mind that Channel 2 overlaps with channels 1, 3, and I believe also 4. So it is not a free channel when there is traffic on the other channels.

Yuxin Chen notifications@github.com schrieb am Do., 5. Apr. 2018, 06:14:

About the chanspec: if I want to capture on channel 2, then chanspec should be 0210, right?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-378815506, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7jYWkqxbqmJPS4Y4ILD3__IMBeMVks5tlZo4gaJpZM4TDHtd .

y-x-c commented 6 years ago

Thanks! I tested on a free channel and injected packets in a controlled speed. It works stably at 0.5s/packet. I am curious about if there is any way to let it support higher speed and finally work in a busy channel? Like, add some strategy to subsampling incoming packets, i.e., do filtering and collect CSI once every x seconds?

y-x-c commented 6 years ago

Another question is how to calculate RSSI from the collected CSI data? And what is the unit of CSI data ?

matthiasseemoo commented 6 years ago

You could try to take the CSI measurement and average the power over the subcarriers and then try to correlate this value with the measured RSSI. But I do not know the unit of the measurements. You will have to consider AGC value durnig reception to calculate a correct value.

On Fri, Apr 6, 2018 at 6:35 PM, Yuxin Chen notifications@github.com wrote:

Another question is how to calculate RSSI from the collected CSI data? And what is the unit of CSI data ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-379308072, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7u2_9n_Qz99a_qOSQCmp_r9G0zyEks5tl5logaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

matthiasseemoo commented 6 years ago

Extracting the CSI always takes a while, you either have to be done before a frame ends (and loose the payload) or you wait until the end of the frame hopeing that you do not receive any other frame until you finished the CSI extraction, otherwise the CSI will be partically overwritten by new CSI values of a followup frame. Even better would be to find out how to avoid the reception of new frames while extracting CSI values.

On Fri, Apr 6, 2018 at 5:27 PM, Yuxin Chen notifications@github.com wrote:

Thanks! I tested on a free channel and injected packets in a controlled speed. It works stably at 0.5s/packet. I am curious about if there is any way to let it support higher speed and finally work in a busy channel? Like, add some strategy to subsampling incoming packets, i.e., do filtering and collect CSI once every x seconds?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-379288822, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7mxoeaL_s0O9lJoj2Hup-OgUHx8Tks5tl4lqgaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

y-x-c commented 6 years ago

Thanks!

some updates:

+ or 2, 0x0, [0, off5]; 
+ or 15, 0x0, [1, off5]

must be executed, otherwise I can not get CSI. Also

+ calls L798 ; 
+ mov RX_HDR_BASE + (17 * RX_HDR_LEN), SPR_RXE_RXHDR_OFFSET

these commands also must be executed. I am not sure the meaning of these parts, can you provide some insights of them? Also, I can not find the definition of off5 and off1, what are the meanings of them?

matthiasseemoo commented 6 years ago

Hi Yuxin,

for us it also worked to extract CSI information from ACK frames, so short frames should generally work. But we also never intended to extract CSI for every frames but only from selected ones.

Here is the ucode with comments, the best way would be to first check the bandwidth of a received frames and then decide how much information needs to be copied, but you can also hardcode to copy less information: // SPINSPINSPIN: this seems the first nice place where to run a // spin on the incoming packet

define SPIN_LENGTH (6 + 16)

define SPARE1 r54

spin_rx_header: jext COND_RX_COMPLETE, spin_rx_end jl SPR_RXE_FRAMELEN, SPIN_LENGTH, spin_rx_header spin_rx_end: jl SPR_RXE_FRAMELEN, SPIN_LENGTH, skip+

mov 0, r55
mov    [CMP_FRM_CTRL_FLD], SPARE1
jne    [3,off1], SPARE1, skip+
mov    [CMP_DURATION], SPARE1
jne    [4,off1], SPARE1, skip+
mov    [CMP_DST_MAC_0], SPARE1
jne    [5,off1], SPARE1, skip+
mov    [CMP_DST_MAC_1], SPARE1
jne    [6,off1], SPARE1, skip+
mov    [CMP_DST_MAC_2], SPARE1
jne    [7,off1], SPARE1, skip+
mov    [CMP_SRC_MAC_0], SPARE1
jne    [8,off1], SPARE1, skip+
mov    [CMP_SRC_MAC_1], SPARE1
jne    [9,off1], SPARE1, skip+
mov    [CMP_SRC_MAC_2], SPARE1
jne    [10,off1], SPARE1, skip+
mov 1, r55
jext    COND_RX_COMPLETE, skip+

jne [SHM_CSI_COLLECT], 1, skip+

// check the encoding
and SPR_RXE_PHYRXSTAT0, 0x3, SPARE1
jne r23, 0x0, localskip+
add [0x8bd], 1, [0x8bd] // 802.11b frame

localskip: jne r23, 0x1, localskip+ add [0x8be], 1, [0x8be] // 802.11g frame localskip: jne r23, 0x2, localskip+ add [0x8bf], 1, [0x8bf] // 802.11n frame localskip:

// store source mac address in frames d11rxhdr
or    [8,off1], 0x0, [RX_HDR_NEXMON_SrcMac0]
or    [9,off1], 0x0, [RX_HDR_NEXMON_SrcMac1]
or    [10,off1], 0x0, [RX_HDR_NEXMON_SrcMac2]

// skip csi collection for 802.11b frames
// register 23 contains the frame encoding
je r23, 0x0, skip+

// do not touch the csi
//jmp skip+
// clear rx header
mov RX_HDR_BASE + RX_HDR_LEN, SPARE1
mov    RX_HDR_BASE + (17 * RX_HDR_LEN), SPR_BASE5

erase_hdr: // L456 mov 0x0, [0x00,off5] sub SPR_BASE5, 0x1, SPR_BASE5 jges SPR_BASE5, SPARE1, erase_hdr- // LOOP

// read chanest table and store it in RXHDR
phy_reg_write(0x00d,73)

mov 0, SPARE1
mov    (RX_HDR_BASE + RX_HDR_LEN), SPR_BASE5

// copy CSI information for 1st 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 15, repeat-

// copy CSI information for 2nd 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 30, repeat-

// copy CSI information for 3rd 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 45, repeat-

// copy CSI information for 4th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 60, repeat-

// copy CSI information for 5th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 75, repeat-

// copy CSI information for 6th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 90, repeat-

// copy CSI information for 7th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 105, repeat-

// copy CSI information for 8th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 120, repeat-

// copy CSI information for 9th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 135, repeat-

// copy CSI information for 10th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 150, repeat-

// copy CSI information for 11th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 165, repeat-

// copy CSI information for 12th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 180, repeat-

// copy CSI information for 13th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 195, repeat-

// copy CSI information for 14th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 210, repeat-

// copy CSI information for 15th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 225, repeat-

// copy CSI information for 16th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 240, repeat-

// copy CSI information for 17th 15 subcarriers
or 2, 0x0, [0, off5]
or 15, 0x0, [1, off5] // NexmonExt: number of uint32 iq samples

contained in this header add SPR_BASE5, 2, SPR_BASE5 repeat: phy_reg_write(0x00e, SPARE1) phy_reg_read_to_shm_off(0x00f, 0, off5) phy_reg_read_to_shm_off(0x010, 1, off5) add SPR_BASE5, 2, SPR_BASE5 add SPARE1, 1, SPARE1 jl SPARE1, 255, repeat-

mov 1, [SHM_CSI_COPIED]

skip:

Matthias

On Thu, Apr 12, 2018 at 7:34 PM, Yuxin Chen notifications@github.com wrote:

Thanks!

some updates:

  • I compared the average CSI measurement and RSSI, the trend is consistent.
  • Now CSI capturing works well for long frames, but for short frames like BlockACK, still not works well. Since I only want to get CSI in 20MHz channel, is there a possible way to only copy 64 subcarriers value instead of all the ~256 subcarriers? I tried to remove some repeat parts in ucode.patch, and I found that
  • or 15, 0x0, [1, off5] must be executed, otherwise I can not get CSI. Also
  • calls L798 ;
  • mov RX_HDR_BASE + (17 * RX_HDR_LEN), SPR_RXE_RXHDR_OFFSET`` these commands also must be executed. I am not sure the meaning of these parts, can you provide some insights of them? Also, I can not find the definition ofoff5andoff1`, what are the meanings for them?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-380885598, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7lvxEv2oNc2jfrRDNHmjNXsSFe00ks5tn5BCgaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

y-x-c commented 6 years ago

I did more comparison between CSI and RSSI. It looks like that the CSI data is obtained after AGC, i.e., CSI data is relative instead of absolute. Is there anyway we can get RSSI or AGC gain at the same time, so we can convert CSI value to an absolute one?

matthiasseemoo commented 6 years ago

For each received frame, you get a wlc_d11rxhdr that contains the measured rx power per receive antenna: https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/blob/master/src/csi_extraction.c#L103

On Tue, Apr 24, 2018 at 11:38 PM, Yuxin Chen notifications@github.com wrote:

I did more comparison between CSI and RSSI. It looks like that the CSI data is obtained after AGC, i.e., CSI data is relative instead of absolute. Is there anyway we can get RSSI or AGC gain at the same time, so we can convert CSI value to an absolute one?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-384088517, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7rq94w8gzsUvHB5Tzlw8N4FPadsGks5tr5tTgaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

y-x-c commented 6 years ago

I replaced https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42c22893833e/src/csi_extraction.c#L141 with

memcpy(udpfrm->kk1, wlc_rxhdr->rxpwr, sizeof(wlc_rxhdr->rxpwr));

and the reported values are all zeros. Do you have any suggestions?

matthiasseemoo commented 6 years ago

Ok, then you need to analyze the ucode and check which value is written into the d11rxhdr. Maybe no value is written into the rxpwr array.

On Thu, Apr 26, 2018 at 8:03 PM, Yuxin Chen notifications@github.com wrote:

I replaced https://github.com/seemoo-lab/mobisys2018_nexmon_channel_ state_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42 c22893833e/src/csi_extraction.c#L141 with

memcpy(udpfrm->kk1, wlc_rxhdr->rxpwr, sizeof(wlc_rxhdr->rxpwr));

and the reported values are all zeros. Do you have any suggestions?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-384734317, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7kgS9P616xHt4KwCxSUC3Y0lg7LUks5tsgvhgaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

y-x-c commented 6 years ago

Do you have any suggestion which part should I look into?

And what does this line work for? https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42c22893833e/src/csi_extraction.c#L213

matthiasseemoo commented 6 years ago

The line 213 is due to the way we perform the hook. I needed to create a hook before the wlc_rxhdr gets overwritten. At the end of process_frame_hook I simply call the function that was supposed to be called by the hooked function.

Write me an email, than I can give you further instructions on the ucode.

On Tue, May 1, 2018 at 11:08 PM, Yuxin Chen notifications@github.com wrote:

Do you have any suggestion which part should I look into?

And what does this line work for? https://github.com/seemoo-lab/mobisys2018_nexmon_channel_ state_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42 c22893833e/src/csi_extraction.c#L213

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-385790998, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7kSy3fGL37Rn36aXN35bvbJ3Gj1Hks5tuM7egaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

matthiasseemoo commented 6 years ago

I had another look at the code and the wlc_phy_rssi_compute function is supposed to to calculate the rssi value. the return value of this function should be the average of the rssi over all antennas.

On Wed, May 2, 2018 at 5:57 PM, Matthias Schulz < mschulz@seemoo.tu-darmstadt.de> wrote:

The line 213 is due to the way we perform the hook. I needed to create a hook before the wlc_rxhdr gets overwritten. At the end of process_frame_hook I simply call the function that was supposed to be called by the hooked function.

Write me an email, than I can give you further instructions on the ucode.

On Tue, May 1, 2018 at 11:08 PM, Yuxin Chen notifications@github.com wrote:

Do you have any suggestion which part should I look into?

And what does this line work for? https://github.com/seemoo-lab/mobisys2018_nexmon_channel_sta te_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42 c22893833e/src/csi_extraction.c#L213

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-385790998, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7kSy3fGL37Rn36aXN35bvbJ3Gj1Hks5tuM7egaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany

y-x-c commented 6 years ago

from this line, looks like no value is returned by wlc_phy_rssi_compute

https://github.com/seemoo-lab/nexmon/blob/bee98fd8f6fdc4330e82aa39df10cfdcbd4e4870/patches/common/wrapper.c#L1339

I also try to copy PhyRxStatus_3 just before this line, but the value copied is always the same https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42c22893833e/src/csi_extraction.c#L184

matthiasseemoo commented 6 years ago

you might need to define a return value in the wrapper.c file. The value for PhyRxStatus_3 is only meaningful in frames that do not contain CSI. I think I overwrote it in CSI frames.

On Thu, May 3, 2018 at 6:18 PM, Yuxin Chen notifications@github.com wrote:

from this line, looks like no value is returned by wlc_phy_rssi_compute

https://github.com/seemoo-lab/nexmon/blob/bee98fd8f6fdc4330e82aa39df10cf dcbd4e4870/patches/common/wrapper.c#L1339

I also try to copy PhyRxStatus_3 just before this line, but the value copied is always the same https://github.com/seemoo-lab/mobisys2018_nexmon_channel_ state_information_extractor/blob/9c8ff2841a1dbd876ee5f1f8266e42 c22893833e/src/csi_extraction.c#L184

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/mobisys2018_nexmon_channel_state_information_extractor/issues/2#issuecomment-386351877, or mute the thread https://github.com/notifications/unsubscribe-auth/ALP_7sOyyUoiVScv2lDALVqPWoUPt-_wks5tuy3FgaJpZM4TDHtd .

-- Matthias Schulz Secure Mobile Networking Lab - SEEMOO

Email: matthias.schulz@seemoo.tu-darmstadt.de Web: http://www.seemoo.de/mschulz Phone (new): +49 6151 16-25478 Fax: +49 6151 16-25471

Department of Computer Science Center for Advanced Security Research Darmstadt Technische Universität Darmstadt Mornewegstr. 32 (Office 4.2.10, Building S4/14) D-64293 Darmstadt, Germany