how to maintain the data rate and also change the channel automatically

[jinzhang-unsw]

I follow the way in FAQ1 to change the data rate like this:

echo 0x4214 | sudo tee  /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/'mac_addr'/rate_scale_table

The 16 possible transmit rates have changed accordingly. But I find the actual tx rate does not turn to it. I use

iw dev wlan0 link

to show the link state. If I use the default transmit rate which will increase mcs slowly, Iog_to_file can log the csi and always show:

received 393 bytes: id: 26 val: 1 seq: 0 clen:393
received 213 bytes: id: 26 val: 1 seq: 0 clen:213

Is there any problem? And is it possible to automatically change the AP and client to 5G or another channel in 2.4G? I want log csi of different channels in tdma way like sensor network.

Jin

[dpward]

Hi Jin,

Which rate specifically are you setting? Note that 0x4214 which you mentioned corresponds to 2 Mbps — a legacy 802.11 rate that will not provide CSI — see FAQ #5.

The tx bitrate that is printed when you run

iw dev wlan0 link

will not be accurate after you use debugfs to set a transmit rate in the iwlwifi driver. Have you tried taking a packet capture using Wireshark on the receiving station, and verified that frames actually use a different rate than what you configured? To do this, you will first need to create an additional interface for this adapter in monitor mode, like this:

sudo iw phy phy0 interface add mon0 type monitor
sudo ip link set mon0 up

and then use Wireshark to capture the mon0 interface while you are transmitting from the other station. (The wlan0 interface will still operate in client or AP mode and will be used for sending/receiving traffic.)

Regarding your other question: in AP/client mode, the channel is configured at the AP, and the client switches to this channel when it is associating with the AP. If you are running hostapd, for example, please refer to its documentation on how to select the channel.

[jinzhang-unsw]

After I set different data rates like 0x1A90E, the 16 data rates have changed but the last tx rate in the rate_scale_table does not changed. And several seconds later the 16 data rates all change back to 0x420A.

I use iw dev wlan0 link to show the current tx bitrate.

The default 16 data rates of the AP will slowly increase the MCS and from SISO to MIMO2. I use this default settings to test CSI and ping the IP address of AP for 800 packets (one packet per second without packets loss). But the number of CSI traces I have will be just from 20 to 95 which is too few for experiments. So do you know what the problem is?

Jin

[dpward]

Hi Jin,

The last tx rate in rate_scale_table will not be accurate either once you set the transmit rate. The value of fixed rate in rate_scale_table should change instead. To be sure what rate you are achieving, measure the rate using Wireshark with monitor mode.

I'd like to get a few additional details:

• Are you using a hardware AP, or are you running hostapd on another system with an Intel 5300 adapter? In the latter case, I assume that you are trying to set the transmit rate from a client (rather than from the AP)?
• If you try setting a new legacy (802.11a/b/g) rate, does the rate remain set properly, or does it change back eventually?
• What happens if you try a High Throughput (802.11n rate) having 20 MHz channel width, normal guard interval, single antenna and MCS 0-7?

Thanks!

[dhalperi]

The other thing that could be happening is if you pick a rate that the AP cannot receive, you'll get kicked off and forced to re-associate, and your rate table will reset as a result. Is this a possibility?

The other thing you should send us is the AP's capabilities. This would be the output of iw list (or something like that, it's been a long time).

[jinzhang-unsw]

Sorry I find sometimes I forget dhclient wlan0 to acquire the ip address. Now in most time the system can maintain the data rate I set.

If I set like 0x1C90E that use 3 tx antennas, the CSI I get still is the 2_3_30 matrix. Under the default settings, the driver has most MCS 15 that only use 2 antennas. Does the interference cause this?

I use ping to send like 200 packets then CSI will have more than 400 traces, almost double size. Is it normal?

By the way I try the old version in which the step 5 show the way to install hostap. And there is error when compiling. It shows netlink/genl/genl.h: no such file or directory.

Very grateful for your help :) Jin

[dhalperi]

First off, 0x1c90e is not a 3-stream rate, it's a 2-stream rate (MCS 14, 40 MHz... right?). So you should get a 2x3x30 CSI measurement assuming the receiver has 3 RX antennas.

• Please review FAQ number 1 to understand rates. http://dhalperi.github.io/linux-80211n-csitool/faq.html
• Please review FAQ number 2 to understand what Ntx and Nrx mean with CSI and why the measurement is therefore only 2x3.

Second, if the AP's rate selection stops at MCS 15, this makes me suspect that 3-stream rates are not supported, either by your devices, configuration, or environment:

1. your AP hardware or configuration does not support 3-stream rates, or
2. there is something wrong with one of the antennas on one of the devices (AP or client) so that there are only actually 2 usable spatial streams, or
3. the physical RF channel between your devices does not support three spatial streams. Maybe it is a long link with low path redundancy?

[dpward]

Jin, regarding your other questions: you might prefer to just install the prebuilt package for hostapd instead of building it from the source code:

sudo apt-get install hostapd

(You need the "universe" repository enabled to do this.) However if you would rather build it manually, you need to install the development package for libnl.

Regarding the number of entries in the trace file — I would suggest using Wireshark on the client to understand the traffic you are actually receiving, which will hopefully identify the discrepancy.

[jinzhang-unsw]

I try another router and also find only 2 streams are available. Maybe the current hardware or other environment does not support. I tried 0x1c113 and the data rate always turn back the default one later.

I use wireshark on the client to monitor the traffic. And I find whenever the client request one packet, info is Echo (ping) request ... (reply in #), the AP will reply two packets, one info is Echo (ping) reply ... (request in #) and another info is Echo (ping) reply ..., without (request in #). Two packets have same id and seq. Is it normal?

[dpward]

Does your Intel adapter on the client have antennas wired to all three ports? Also in our experience at MIT we seemed to believe that this adapter often experiences crosstalk on antenna port 3 (the one in the center) from antenna ports 1 and 2.

Normally an ICMP Echo Request will only cause one ICMP Echo Reply to be generated on the other end (assuming you are not pinging the broadcast address), so I am not sure why you are seeing two replies from the AP — but at least it explains why you have twice the number of CSI entries that you expected in the trace file.

[jinzhang-unsw]

For the multiple replies problem, I use the laptop as client and router as AP. Wireshark shows one reply has 81 tx data rate and another one has 108. And sometimes if AP replies once, the received CSI will be the 1*3*30 matrix that only one tx antenna data. If AP replies twice, CSI will be 2*3*30. I try another different router and it also happens. So do you think what the problem is? Or do I better use another laptop and use injection mode?

[dpward]

Although you are overriding the rate selection algorithm on the client in order to force a consistent outgoing rate, the incoming rate may still vary, because your hardware AP is continuing to use its own rate selection algorithm when transmitting.

Regarding why you are receiving two ICMP replies per request — did you try two different brands/models of hardware AP (not two units of the same model)? When you send other traffic through the AP to the client, do you see twice as many receive packets as expected, or does this only occur with ICMP? What happens if you connect a different laptop to this access point that is not using the CSI Tool — are there two replies visible in Wireshark when you send ICMP requests?

[jinzhang-unsw]

I have tried different models of AP and multiple replies still happen. I also use my mac laptop and use ping command to request pkts. Wireshark shows only one reply will be sent by AP.

[dpward]

So just as a point of reference: I'm able to use the CSI Tool under Ubuntu 14.10 with a D-Link DIR-655 router, and when I use the ping command with the local IP address of the router, I don't have any duplicate ICMP replies, according to Wireshark.

Is the interface always in the same mode when you capture packets with Wireshark on these different systems? For example, are you perhaps doing a "monitor mode" capture with the CSI Tool (which shows 802.11 frame headers, etc.), but doing a regular capture using your Mac? Better yet, do you have a way to upload the packet captures so that I can open them?

[jinzhang-unsw]

I change to the same ubuntu version and duplicate replies still happen. I have recorded two capture logs and you can download them here. https://space.zeo.net/g/1pm4y The normal one has a reply. But most time I have the another one with duplicate replies. I do not have a D-Link router around....

[dpward]

Your access point is retrying transmissions (at the MAC layer), which is resulting in duplicate ICMP echo replies arriving from your AP. Retransmissions can occur when CSMA/CA acknowledgments are not received.

In exp_feb26_anormal.pcapng, frame 37 is a retransmission of frame 35. Using Wireshark to expand the contents of the frame, you will see:

IEEE 802.11 QoS Data, Flags: ....R.F.
    Frame Control Field: 0x880a
        Flags: 0x0a
            .... 1... = Retry: Frame is being retransmitted

In frame 35, the Retry bit is 0 instead.

Note that retransmissions are even seen occasionally in exp_feb26_normal.pcapng: frame 85 is a retransmission of frame 83.

[dhalperi]

So, looks like this is normal behavior. Thanks @dpward for debugging!