search

aircrack-ng / rtl8812au

RTL8812AU/21AU and RTL8814AU driver with monitor mode and frame injection
GNU General Public License v2.0
3.55k stars 775 forks source link

ibss support #311

Closed lucabianchi91 closed 3 years ago

lucabianchi91 commented 5 years ago

Hi, we are experimenting with two types of devices running OpenWrt 18.06. Everything is ok in AP and Station Mode while with ibss we are not able to exchange any packet after the two devices successfully join the same cell. Please note that this issue was not present with the original Edimax driver 8812au (plus some patches) that however performs much more poorly than this driver in ap and station mode. Is this a known issue? Do you plan to solve it in the near future? Thanks a lot.

Hurricos commented 5 years ago

Upon seeing this issue come up I can also pitch in and confirm I had the same problem using two rtl8811au chips with the v5.3.4 of this driver. There were frequently IBSS cell split issues, but even when a stable cell was working between the two devices, the devices acted as you suggest @lucabianchi91.

I can add one thing of use: by using horst and setting a third device into monitor mode, one station was actually transmitting data packets (I did a multicast ping), but the other refused.

@lucabianchi91, if you'll keep up with this, I'll eventually try bisecting the issue, as this repo sources from very old Edimax drivers. However, you shouldn't expect 11ac speeds out of IBSS on these devices.

Hurricos commented 5 years ago

@lucabianchi91 I've poked around and discovered a solution: IBSS functions normally in v5.2.20.

Hurricos commented 5 years ago

I'm in the process of manually bisecting it. I am quite surprised to find that the problem is not present in the original v5.3.4 merge!

Hurricos commented 5 years ago

After manually bisecting and failing to find the issue, I reviewed my testing configuration. I have 1 x RTL8811AU + 1 x RTL8811CU (with working IBSS) on my laptop, and 1 x RTL8811AU on another machine. I have them set up to enter Ad-hoc mode via NetworkManager on channel 36 (802.11a).

From my laptop via an RTL8811AU device (on the most recent commit on v5.3.4):

$ ping6 ff02::1%wlx000f0072ba8f
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=30 ttl=64 time=0.066 ms
64 bytes from fe80::a700:ab1:12ca:853a%wlx000f0072ba8f: icmp_seq=30 ttl=64 time=3.44 ms (DUP!)
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=30 ttl=64 time=4.49 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=31 ttl=64 time=0.089 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=31 ttl=64 time=4.63 ms (DUP!)
64 bytes from fe80::a700:ab1:12ca:853a%wlx000f0072ba8f: icmp_seq=31 ttl=64 time=4.86 ms (DUP!)
# I unplugged the RTL8811CU here
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=32 ttl=64 time=0.078 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=32 ttl=64 time=6.01 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=33 ttl=64 time=0.080 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=33 ttl=64 time=4.57 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=34 ttl=64 time=0.066 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=34 ttl=64 time=4.45 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=35 ttl=64 time=0.044 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=35 ttl=64 time=4.46 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=36 ttl=64 time=0.081 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=36 ttl=64 time=4.50 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=37 ttl=64 time=0.038 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=37 ttl=64 time=5.38 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=38 ttl=64 time=0.077 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=38 ttl=64 time=4.41 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=39 ttl=64 time=0.078 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=39 ttl=64 time=8.19 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=40 ttl=64 time=0.075 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=40 ttl=64 time=4.41 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=41 ttl=64 time=0.075 ms
64 bytes from fe80::e79d:822e:d738:694a%wlx000f0072ba8f: icmp_seq=41 ttl=64 time=9.70 ms (DUP!)
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=42 ttl=64 time=0.084 ms
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=43 ttl=64 time=0.042 ms
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=44 ttl=64 time=0.083 ms
64 bytes from fe80::7ac1:696d:8e29:30b2%wlx000f0072ba8f: icmp_seq=45 ttl=64 time=0.082 ms

What this is telling me is that the RTL8811CU chipset is causing the RTL8811AUs to work correctly, and about 10 seconds after it is removed from the cell, the cell fails.

lucabianchi91 commented 5 years ago

We are on OpenWrt, so we configured the network using iw instead of the network manager. We tried the 5.2.20 version on 2 RT8814AU modules and we can confirm your results:

Hurricos commented 5 years ago

NetworkManager doesn't do anything fancy that iw does not, except unintentionally join pre-saved networks. The practical result that I have observed from that is that the devices go into STA mode to associate with my AP when I first plug them in and before I disable NetworkManager on them, which sets them onto the right channel and caches some SSIDs from received probes.

In practice, this means that if you are using only two RTL88XXAU dongles, that you can 'tune' them into noticing each other through connecting them first to an access point:

# Use `wpa_supplicant` to associate, then kill the supplicant process
wpa_supplicant -i wlan0 -Dnl80211 -c/etc/wpa_supplicant.conf
.,.,.

# Set wlan0 down and put it into IBSS
ip l set wlan0 down ; iw dev wlan0 set type ibss ; ip l set wlan0 up
iw dev wlan0 ibss join my_mesh 5180

If you use horst to monitor what's going on (it turns out, rtl8812au is REALLY good in monitor-mode):

ip l set wlan0 down
iw dev wlan0 set type monitor
ip l set wlan0 up
horst -i wlan0

... you should see that this time, they do not break into different cells.

This odd behavior probably has to do with scanning in IBSS being impaired:

ip l set wlan0 down ; iw dev wlan0 set type ibss ; ip l set wlan0 up ; iw dev wlan0 scan

... should return nothing, which means that if the devices are only scanning from IBSS mode, they will not even notice each other.

Unfortunately, I have no additional clues as to why they do not transmit anything in IBSS; considering my observations about the IBSS breaking down 10 seconds after, it probably has to do with an SSID buffer somewhere - in particular, that when the devices are in IBSS, probes from one such device are unable to cause an insertion into the station list of another.

Regarding low-rate transmission: don't forget, iw list actually will tell you whether the wireless interface is advertising HT-IBSS or VHT-IBSS (just grep for either). Based on what I know about the mt76 driver on e.g. the mt7610u chipset, I would recommend using those rather than rtl8814au.

Much more information about the state of alternative association modes under the rtl8812au driver can be found here, but since they advise to follow Ralink's build processes to a tee, they aren't very useful.

kimocoder commented 5 years ago

v5.3.4 just got some MESH / IBSS patches along with lots of others. Try updating with "git pull" and build again and check please. Report back,

Hurricos commented 5 years ago

This is interesting. I'm in the middle of compiling from a recent pull, and am about to test a longer-distance AP <-> STA using v5.3.4 on both ends, so I'll perhaps try IBSS out too.

Hurricos commented 5 years ago

Unfortunately, no difference. @kimocoder I'm assuming you mean in the last week or so.

lucabianchi91 commented 5 years ago

Hi, we tried the last commit and we were still not able to communicate. This is the log of wpa_supplicant:

root@OpenWrt:~# wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
wlan0: Trying to associate with SSID 'adhoctest'
wlan0: Associated with 02:11:87:d1:e7:21
wlan0: CTRL-EVENT-CONNECTED - Connection to 02:11:87:d1:e7:21 completed [id=0 id_str=]
WMM AC: Missing IEs
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

We tried even with iw (so without encryption) and still no communication. Furthermore, we noticed with

iw dev wlan0 scan

that no capabilities are reported in the beacon:

BSS 02:11:87:78:87:36(on wlan0) -- joined
        TSF: 303268016 usec (0d, 00:05:03)
        freq: 5180                                  
        beacon interval: 100 TUs
        capability: IBSS (0x0002)   
        signal: 0.00 dBm         
        last seen: 0 ms ago                   
        SSID: adhoctest            
        Supported rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
        DS Parameter set: channel 36
        IBSS ATIM window: 0 TUs ERP: <no flags>

Is that related to the fact to the wpa_supplicant message "WMM AC: Missing IEs" ? Thanks

Hurricos commented 5 years ago

@lucabianchi91 The lack of capabilities when setting into IBSS mode is expected: many manufacturers implement Ad-hoc as an afterthought without capabilities like HT-IBSS - which is available with some iwlwifi based wireless cards, like mine:

$ iw list
:
    Device supports TX status socket option.
    Device supports HT-IBSS.
    Device supports SAE with AUTHENTICATE command
:

When they lack those capabilities, they don't advertise them. You will find similar things when looking at the beacons advertised by e.g. 802.11g APs.

If this is anything to go by, "WMM AC: Missing IEs" is to be expected if you are using the rtw_power_mgnt=0 module option.

Sidenote: Could you supply your wpa_supplicant?

lucabianchi91 commented 5 years ago

@Hurricos I was supposing that capabilities listed by iw were supported in all modes, that's why I found strange that beacon:

root@OpenWrt:~# iw list
Wiphy phy0
    max # scan SSIDs: 9
    max scan IEs length: 2304 bytes
    max # sched scan SSIDs: 0
    max # match sets: 0
    max # scan plans: 1
    max scan plan interval: -1
    max scan plan iterations: 0
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
    Available Antennas: TX 0 RX 0
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * monitor
         * P2P-client
         * P2P-GO
    Band 1:
        Capabilities: 0x1b73
            RX LDPC
            HT20/HT40
            Static SM Power Save
            RX Greenfield
            RX HT20 SGI
            RX HT40 SGI
            RX STBC 3-streams
            Max AMSDU length: 7935 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT Max RX data rate: 450 Mbps
        HT TX/RX MCS rate indexes supported: 0-23
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps
            * 5.5 Mbps
            * 11.0 Mbps
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (20.0 dBm)
            * 2417 MHz [2] (20.0 dBm)
            * 2422 MHz [3] (20.0 dBm)
            * 2427 MHz [4] (20.0 dBm)
            * 2432 MHz [5] (20.0 dBm)
            * 2437 MHz [6] (20.0 dBm)
            * 2442 MHz [7] (20.0 dBm)
            * 2447 MHz [8] (20.0 dBm)
            * 2452 MHz [9] (20.0 dBm)
            * 2457 MHz [10] (20.0 dBm)
            * 2462 MHz [11] (20.0 dBm)
            * 2467 MHz [12] (20.0 dBm) (no IR)
            * 2472 MHz [13] (20.0 dBm) (no IR)
            * 2484 MHz [14] (20.0 dBm) (no IR)
    Band 2:
        Capabilities: 0x1b73
            RX LDPC
            HT20/HT40
            Static SM Power Save
            RX Greenfield
            RX HT20 SGI
            RX HT40 SGI
            RX STBC 3-streams
            Max AMSDU length: 7935 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT Max RX data rate: 450 Mbps
        HT TX/RX MCS rate indexes supported: 0-23
        VHT Capabilities (0x03c054b2):
            Max MPDU length: 11454
            Supported Channel Width: neither 160 nor 80+80
            RX LDPC
            short GI (80 MHz)
            TX STBC
            SU Beamformee
            +HTC-VHT
        VHT RX MCS set:
            1 streams: MCS 0-9
            2 streams: MCS 0-9
            3 streams: MCS 0-9
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        VHT RX highest supported: 1300 Mbps
        VHT TX MCS set:
            1 streams: MCS 0-9
            2 streams: MCS 0-9
            3 streams: MCS 0-9
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        VHT TX highest supported: 1300 Mbps
        Bitrates (non-HT):
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 5180 MHz [36] (20.0 dBm)
            * 5200 MHz [40] (20.0 dBm)
            * 5220 MHz [44] (20.0 dBm)
            * 5240 MHz [48] (20.0 dBm)
            * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
            * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
            * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
            * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
            * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
            * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
            * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
            * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
            * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
            * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
            * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
            * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
            * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
            * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
            * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
            * 5720 MHz [144] (20.0 dBm) (no IR, radar detection)
            * 5745 MHz [149] (20.0 dBm)
            * 5765 MHz [153] (20.0 dBm)
            * 5785 MHz [157] (20.0 dBm)
            * 5805 MHz [161] (20.0 dBm)
            * 5825 MHz [165] (20.0 dBm)
            * 5845 MHz [169] (disabled)
            * 5865 MHz [173] (disabled)
            * 5885 MHz [177] (disabled)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * new_station
         * set_bss
         * join_ibss
         * set_pmksa
         * del_pmksa
         * flush_pmksa
         * remain_on_channel
         * frame
         * set_channel
         * connect
         * disconnect
    Supported TX frame types:
         * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * IBSS: 0xd0
         * managed: 0x40 0xd0
         * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    WoWLAN support:
         * wake up on anything (device continues operating normally)
    software interface modes (can always be added):
         * monitor
    interface combinations are not supported
    Device supports scan flush.

This is the wpa_supplicant.conf (which works well with mt76 modules): 

root@OpenWrt:~# cat /etc/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant

network={
    ssid="adhoctest"
    mode=1
    frequency=5180
    proto=RSN
    key_mgmt=WPA-PSK
    pairwise=CCMP
    group=CCMP
    psk="mypassword"
}
Hurricos commented 5 years ago

@lucabianchi91 as I mentioned, there are some elements of the capability list reported back by iw that talk explicitly about IBSS (like HT-IBSS/VHT-IBSS, which are conspicuously missing). Try taking a look at beacons from some other non-Qualcomm/Atheros wireless devices in ad-hoc mode, and you will see they rarely list much more than the standard 802.11abg capabilities.

Before I go on, I should say that I am no expert, nor am I professionally studied, in the workings of the 802.11 IEEE standard.

That said:

I think I've figured one thing out: Supported {RX,TX} frame types: stanza appears to be talking about sub-types of management frames (Wikipedia on Frame Types). My laptop's WiFi card works OK in IBSS, with the RX line * IBSS: 0x40 0xb0 0xc0 0xd0; compare that to the out the output from iw list from a FullMAC device (a RPi3). You'll notice that the interface types it supports don't get re-listed under the Supported {RX,TX} frame types stanza, because they're mostly not made available to the drivers - it's all done in firmware.

I have to check the rtl8811CU adapter that I know functions fine in IBSS; I know all of these devices implement a MAC layer (check the product pages on the right hand side here), so the original developers might be using it better to do IBSS on the newer rtl8811CU chipset. Hopefully, we get something out of this soon - and with the significantly improved debug logging from recent commits, that might be easier (though that hardly guarantees we'll get strong IBSS support out of these).

Better IBSS support might come with rewriting this as a mac80211 interface, but as mentioned long ago, that's hard. Also I'm not a driver developer so wtf.

minimal1 commented 5 years ago

@lucabianchi91 I have same problem :( Do you solve this?

cedricbambooza commented 3 years ago

pls consider closing the issue, when it's solved by now :)

bakcsa83 commented 2 years ago

Is this issue actually fixed? I can reproduce the same problem on RPi/x86 linux with 3 different wifi adapter that come with RTL8812AU. Adapters can be set to IBSS mode, they join the same cell but communication does not work.