Problems connecting from android phone

[rakeshbala]

I'm trying to measure CSI for connections between an Android based smart phone and the intel adapter. The problem is that the phone disconnects after a few seconds after connecting to the intel adapter in AP mode. Then re-connects, stays for a 4-5s and then again disconnects.

Also I've noted that when using the internet from the phone, while connected, the connection remains open for as long as I keep using the internet. (i.e it seems like the phone loses connection when there is no network activity - And I've switched off 'wi-fi off during sleep' and 'wi-fi optimization' on the phone.)

When connecting from a laptop I'm not facing any such issues. Can this be related to the modified driver/firmware ? Any pointers on what can I do to resolve this?
(I have the adb logs when the phone gets connected/disconnected, but I couldn't discern any useful information from it. Let me know if you want me to post it here.)

I also have another question.
Is there a way to distinguish between packets (csi collecte) from two different devices connected to the ap. (Or at least find them out according to the time stamp information. According to my understanding right now the time stamp recorded in the CSI log and in a packet capture (For e.g. using wireshark) doesn't represent the same thing.) Or am I completely wrong in my assumptions?

[dpward]

I would suggest looking in the hostapd log as well — it may have clues.

One way to distinguish CSI between different devices is for the driver to log received MPDUs in addition to the beamforming information. To do this, set the connector_log driver parameter to 0x5 (which is IWL_CONN_BFEE_NOTIF_MSK | IWL_CONN_RX_MPDU_MSK). Before each beamforming notification (CSI) message, there will be a received MPDU message that corresponds to it. If you are using the MATLAB/Octave code to parse the connector log file, for example, it will require minor modification to parse the received MPDU message and extract the address from the 802.11 header.

[rakeshbala]

I had tried using 0x5 flag. But it seemed to have returned the same information in the CSI log although more packets where being logged. I was getting this information by stepping through the lines extracting the information in log_to_file.c. I guess I was looking in the wrong place. Is the file needing modification, read_bf_file.m or is it drivers/net/wireless/iwlwifi/iwl-agn-lib.c or is it something else
? I might be missing something. I'll try both the suggestions. Thanks.

[dpward]

Can you try increasing the log level in the hostapd configuration?

When parsing the connector log, the MATLAB/Octave code will skip over any messages that are not beamforming information messages (0xbb). You will have to add to code to process the received MPDU messages (0xc1).

[rakeshbala]

The current log level is :
logger_syslog=-1
logger_syslog_level=0
logger_stdout=-1
logger_stdout_level=0

(From the sample config file supplied with tool) -- And it says 0 is the highest.

I still get the same messages in the log file:

Configuration file: /etc/ap-hotspot.conf
Failed to update rate sets in kernel module
Using interface wlan0 with hwaddr ... and ssid 'apnew'
wlan0: AP-STA-CONNECTED ...

[rakeshbala]

And I get this when I checked syslog:
hostapd: wlan0: STA ... IEEE 802.11: disassociated due to inactivity
hostapd: wlan0: STA ... MLME: MLME-DISASSOCIATE.indication(..., 4)
hostapd: wlan0: STA ... MLME: MLME-DELETEKEYS.request(...)
hostapd: wlan0: STA ... IEEE 802.11: deauthenticated due to inactivity
hostapd: wlan0: STA ... MLME: MLME-DEAUTHENTICATE.indication(..., 2)
hostapd: wlan0: STA ... MLME: MLME-DELETEKEYS.request(...)

_But this is logged long after the device actually disconnects_

[dpward]

You can find similar issues with other chipsets using hostapd: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659059

I'm not sure this issue is specific to the CSI Tool driver or firmware; to narrow down the issue, you probably need to obtain a different wireless adapter that also supports AP mode, and try it in place of the Intel adapter to see if you get similar behavior. If the cause is the CSI Tool, I'm not sure we have the ability to do anything about it unfortunately (see FAQ 10 and FAQ 9).

[rakeshbala]

Okey. Thanks for the help. I've made some progress.

[rakeshbala]

Is there a place where I can find some sort of documentation on MPDU fields and their relation w.r.t the read in bytes.

[dpward]

You can refer to section 8.3.2.1 in the IEEE 802.11-2012 standard for the MAC data frame format (specifically, Figure 8-30).

From this section:
"Note that Address 1 always holds the receiver address of the intended receiver (or, in the case of group addressed frames, receivers), and that Address 2 always holds the address of the STA that is transmitting the frame."

[dhalperi]

Closing due to idleness. Please reopen if you still have issues.

[rakeshbala]

I have created a new c file very similar to read_bfee.c to read the mpdu packets. The code that I use is something like below for extracing out the address from the bytes passed in:

long long addr1 = (((((((((inBytes[4]<<8)|
                            inBytes[5])<<8)|
                            inBytes[6])<<8)|
                            inBytes[7])<<8)|
                            inBytes[8])<<8)|
                            inBytes[9];

is this correct? (I am using the MAC data frame format from the above mentioned section 8.3.2.1 of the document as reference. However in the logged mac addresses addresses I couldn't find the mac address of the device that I used to connect to the hotspot).

Also when I use connector_log as 0x5 the the tool logs a lot of packets even before I connect to the hotspot using a device. Is this expected behaviour? (However CSI is logged only after I connect a device and use the network as expected)

[swashah]

@rakeshbala : HI, I want to synchronize CSI recorded by two laptops in monitor mode while thord laptop is injecting packets. Can you please suggest how you achieved this, and what modifications you made.