Packets cannot be captured on RT-AC86U

[sohta94]

Hello, @zeroby0

I am looking to get CSI for 4x4 MIMO on ASUS RT-AC86U. I have set up 3 RT-AC86Us with the help of https://github.com/nexmonster/nexmon_csi/discussions/2. I was able to proceed without any problems. (except that I could not use the scp command since I had updated the firmware to the latest version beforehand. https://www.snbforums.com/threads/scp-missing.80716/)

The problem occurred during CSI acquisition. Two of the three RT-AC86Us were unable to capture packets using tcpdump. Specifically, the following commands were executed.

#!/bin/sh

# 1. Reload router firmware:
/sbin/rmmod dhd
sleep 1
/sbin/insmod /jffs/dhd.ko
sleep 1

# 2. Bring up interfaces:
wl -i eth6 up
sleep 1
wl -i eth6 radio on
sleep 1
wl -i eth6 country US
sleep 1
ifconfig eth6 up
sleep 1

# 3. Start CSI collection
param_str=`/jffs/mcp -c 36/80 -C 0xf -N 0xf -d 200`
sleep 1
/jffs/nexutil -Ieth6 -s500 -b -l34 -v${param_str}
sleep 1
/usr/sbin/wl -i eth6 monitor 1
sleep 1

# Collect CSI with TCPdump
datetime=`date +%y%m%d`
sleep 1
/jffs/tcpdump -i eth6 -w /tmp/mnt/sda1/${datetime}_csi_asus_1.pcap dst port 5500

When I execute above command, the packet could not be captured as shown below.

tcpdump: WARNING: eth6: no IPv4 address assigned
tcpdump: listening on eth6, link-type EN10MB (Ethernet), capture size 65535 bytes
^C0 packets captured
21 packets received by filter
0 packets dropped by kernel

However, one of the three RT-AC86Us successfully captured packets.

tcpdump: WARNING: eth6: no IPv4 address assigned
tcpdump: listening on eth6, link-type EN10MB (Ethernet), capture size 65535 bytes
^C31599 packets captured
31665 packets received by filter
57 packets dropped by kernel

Decoding this pcap file with the MATLAB program (https://github.com/nexmonster/nexmon_csi/tree/master/utils/matlab) successfully generated 4x4 CSIs.

All three RT-AC86Us are configured according to the same procedure and we are unable to determine what is causing this difference. I have also rebooted the RT-AC86U and the same phenomenon is still occurring. If you can find the cause of this problem, I would appreciate your help.

[sohta94]

When packets could not be captured, the tcpdump log (/jffs/tcpdump -i eth6) is as follows.

15:29:40.359026 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.359029 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.359031 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 158
15:29:40.359034 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.359037 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 158
15:29:40.359040 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.359043 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 158
15:29:40.367534 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.367540 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 158
15:29:40.367543 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.367545 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 158
15:29:40.367548 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:29:40.377709 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
(This goes on forever.)

When packets could be captured, the tcpdump log is as follows.

15:33:04.163366 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.166634 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.169911 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.173185 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.176385 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.179644 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.182920 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.186195 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.189472 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.192748 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.196023 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.199298 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.202491 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.205757 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.209033 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.212311 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.215725 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 160
15:33:04.215732 00:00:77:6c:31:00 (oui Unknown) > 41:00:00:00:90:00 (oui Unknown) Null Information, send seq 0, rcv seq 0, Flags [Command], length 158
15:33:04.218763 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042
15:33:04.222037 IP 10.10.10.10.5500 > 255.255.255.255.5500: UDP, length 1042

[zeroby0]

Heyo!

Is the firmware version same on all the routers? When using pre-compiled binaries, you'll need to use the same firmware version on the router as the version the binaries are compiled on.

I think I used https://sourceforge.net/projects/asuswrt-merlin/files/RT-AC86U/Release/RT-AC86U_384.19_0.zip/download when compiling.

I'd compile the binaries for the latest version, but my rt-ac86u is broken.

[sohta94]

Thank you!

I manually updated the firmware to that one ASUS WRT-Merlin and it works fine.

Thank you for your answer and for creating this repository.

[zeroby0]

:)) glad that you did. I've added a recommendation to install merlin-wrt in the guide.

I'm closing this Issue, but feel free to reopen or create new issues if you need to. Good day.

[sohta94]

Hello @zeroby0 , thank you for the other day.

I reopened this Issue because I have further questions about getting CSI on RT-AC86U.

I would like to get the CSI for 4 cores and 4 spatial streams (4x4), and I am generating the parameters with the following command.

/jffs/mcp -c 36/80 -C 0xf -N 0xf -d 100.

However, the CSI values for cores 2 and 3 are always 0. The following image shows the CSI amplitude values acquired on three RT-AC86Us.

I have tried to get them by changing some delay values such as 50, 100, 200, referring to https://github.com/nexmonster/nexmon_csi/tree/master/utils/makecsiparams, which says that delay is necessary for 4x4 acquisition, but there is no change.

I am decoding CSI information from PCAP file using https://github.com/nexmonster/nexcsi. Core and spatial streams are obtained by the following Python program created with reference to https://github.com/nexmonster/nexmon_csi/tree/master#analyzing-the-csi.

samples = nexcsi.decoder('rtac86u').read_pcap(pcap_filename)
csi = nexcsi.decoder('rtac86u').unpack(samples['csi'], zero_nulls=True, zero_pilots=True)

ASUS_HEADER_KEY_DICT = {"magic_byte": [0, 4],
                        "src_mac_add": [4, 10],
                        "wifi_num_frame": [10, 12],
                        "CSS": [12, 14],
                        "chanspec": [14, 16],
                        "chipversion": [16, 18]}

with open(pcap_filename, 'rb') as f:
    p = dpkt.pcap.Reader(f)
    for (timestamp, buffer) in p:
        udp_payload_offset = buffer.find(b'\x11\x11\x11\x11')
        core_and_spatialstream_bytes = buffer[udp_payload_offset + ASUS_HEADER_KEY_DICT['CSS'][0]:udp_payload_offset + ASUS_HEADER_KEY_DICT['CSS'][-1]]
        core_and_spatialstream = np.frombuffer(core_and_spatialstream_bytes, dtype=np.uint8)[-1]
        core = core_and_spatialstream % 8
        spatialstream = core_and_spatialstream // 8

If you know the cause of this problem, I would appreciate your help.

[zeroby0]

Are all the antennas on ac86u 5ghz? You'd only have 4x4 if all of them are one band (i think), and if your client device also support 4x4, then a 4x4 link is possible.

That doesn't guarantee it though, you'd need to use iperf3 or something similar to create lots of traffic to force 4x4.

[sohta94]

I followed your advice and was able to get a 4x4. Thank you very much.

[sohta94]

Hi @zeroby0, I am sending you a message with two further questions.

Based on the advice you gave me the other day, I am now able to measure 4x4 CSI. However, when I animate and observe, I find that the values fluctuate violently and sometimes the amplitude values of the subcarriers are zero for about 75% of the second half. I am filtering with src_mac_add in the above program, so the source should be the same. This video shows the nearest neighbor interpolated CSI to 10 fps. If you find the cause of this fluctuation, I would appreciate it if you could let me know.

https://user-images.githubusercontent.com/63134290/216110038-fe6eabbb-5f7d-4255-b452-fc302236d75a.mp4

Additionally, samples['fctl'] and samples['saddr’] decoded by nexcsi were identical for all packets before filtering. Is the nexcsi decoder compatible with the ASUS RT-AC86U?

Thank you again and again for your help.

[zeroby0]

Heyo!

Even though you set the router to operate in 80 MHz in it's UI, it's only the maximum bandwidth. The router/device is still able to transmit in any bandwidth up to 80 MHz. Part of the reason is to support all devices, for example 802.11n devices can operate in 5GHz mode but will only use 20 MHz. And part of it is to save power.

So when you capture a 20Mhz packet, you'll see that the amplitude for the rest of the sub-carriers is 0.

I believe the red here is a 20 MHz packet:

If you need to ensure that your packets have a consistent bandwidth, packet injection might be helpful. But I don't know how to do that. Maybe try filtering out packets that are not 80MHz, and if that doesn't satisfy your needs, try packet injection.

[sohta94]

It was an important reminder to me that not all frames are at 80 MHz. I will try to figure out how to filter only 80 MHz frames.

Thank you very much.

[zeroby0]

Happens, wireless is full of trickery and misdirection 😆

G'day!