search

kaloz / mwlwifi

mac80211 driver for the Marvell 88W8864 802.11ac chip
395 stars 119 forks source link

Wireless goes offline if only one client is left connected #20

Closed Vanav closed 8 years ago

Vanav commented 9 years ago

How to reproduce the issue

Initial state: OpenWRT trunk build, enable wireless and encryption (psk2+ccmp). If using shell, then the only modified file is /etc/config/wireless (see below), next run wifi to bring wireless up.

0) No wireless clients. 1) Do: client A - connect to 2.4 GHz 2) Do: client B - connect to 2.4 GHz 3) Do: client A - disconnect from 2.4 GHz Result: client B - goes offline

Offline means client is associated, wireless connected, but no ping to router. No new lines in syslog, iwinfo wlan0 assoclist shows client normally, ping to router doesn't bring connection up.

If you wait for 10 minutes here, connection of client B is recovered (WPA rekeying GTK). See all logs below.

Test can be continued: 4) Do: client A - connect to 2.4 GHz Result: client B - back online.

Same can be done with 5 GHz on both clients with same result. Encryption is required for this issue. If encryption is disabled, then no issue. How can I fix this?

Contents of the only modified file /etc/config/wireless:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option htmode 'HT20'
        option country 'DE'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2+ccmp'
        option key 'password'
        option ssid '24GHz'      

config wifi-device 'radio1'   
        option type 'mac80211'                                                    
        option channel '36'                                                       
        option hwmode '11a'                                                       
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option htmode 'VHT80'
        option country 'DE'   

config wifi-iface             
        option device 'radio1'
        option network 'lan'    
        option mode 'ap'        
        option encryption 'psk2+ccmp'
        option key 'password'
        option ssid '5GHz'

Cross-post: https://forum.openwrt.org/viewtopic.php?pid=276764#p276764

Vanav commented 9 years ago

Confirmed also using build openwrt_wrt1900ac_snapshot.img (23-Apr-2015 20:20, 9175040 bytes) from https://downloads.openwrt.org/people/kaloz/.

Update: more complete debug log is in next message.

yuhhaurlin commented 9 years ago

Thanks. We will check it.

Vanav commented 9 years ago

This bug is confirmed by other tester [1]. Here is hostapd log at maximum logger level (logger_syslog_level=0).

0) No wireless clients.

1) Do: client A (84:38:38:0f:15:94) - connect to 2.4 GHz
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.11: authentication OK (open system)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-AUTHENTICATE.indication(84:38:38:0f:15:94, OPEN_SYSTEM)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-DELETEKEYS.request(84:38:38:0f:15:94)
Thu Apr 23 20:28:01 2015 daemon.info hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.11: authenticated
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.11: association OK (aid 1)
Thu Apr 23 20:28:01 2015 daemon.info hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.11: associated (aid 1)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-ASSOCIATE.indication(84:38:38:0f:15:94)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-DELETEKEYS.request(84:38:38:0f:15:94)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: event 1 notification
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: start authentication
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.1X: unauthorizing port
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: sending 1/4 msg of 4-Way Handshake
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: received EAPOL-Key frame (2/4 Pairwise)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: sending 3/4 msg of 4-Way Handshake
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: received EAPOL-Key frame (4/4 Pairwise)
Thu Apr 23 20:28:01 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.1X: authorizing port
Thu Apr 23 20:28:01 2015 daemon.info hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: pairwise key handshake completed (RSN)
Thu Apr 23 20:28:02 2015 daemon.info dnsmasq-dhcp[1762]: DHCPREQUEST(br-lan) 192.168.1.116 84:38:38:0f:15:94 
Thu Apr 23 20:28:02 2015 daemon.info dnsmasq-dhcp[1762]: DHCPACK(br-lan) 192.168.1.116 84:38:38:0f:15:94 android

2) Do: client B (00:23:14:07:0e:3c) - connect to 2.4 GHz
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: authentication OK (open system)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-AUTHENTICATE.indication(00:23:14:07:0e:3c, OPEN_SYSTEM)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-DELETEKEYS.request(00:23:14:07:0e:3c)
Thu Apr 23 20:28:38 2015 daemon.info hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: authenticated
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: association OK (aid 2)
Thu Apr 23 20:28:38 2015 daemon.info hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: associated (aid 2)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-ASSOCIATE.indication(00:23:14:07:0e:3c)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-DELETEKEYS.request(00:23:14:07:0e:3c)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: event 1 notification
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: start authentication
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.1X: unauthorizing port
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 1/4 msg of 4-Way Handshake
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: received EAPOL-Key frame (2/4 Pairwise)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 3/4 msg of 4-Way Handshake
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: received EAPOL-Key frame (4/4 Pairwise)
Thu Apr 23 20:28:38 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.1X: authorizing port
Thu Apr 23 20:28:38 2015 daemon.info hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: pairwise key handshake completed (RSN)
Thu Apr 23 20:28:38 2015 daemon.info dnsmasq-dhcp[1762]: DHCPREQUEST(br-lan) 192.168.1.150 00:23:14:07:0e:3c 
Thu Apr 23 20:28:38 2015 daemon.info dnsmasq-dhcp[1762]: DHCPACK(br-lan) 192.168.1.150 00:23:14:07:0e:3c HP

3) Do: client A - disconnect from 2.4 GHz
Result: client B - goes offline
Thu Apr 23 20:28:59 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 WPA: event 2 notification
Thu Apr 23 20:28:59 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.1X: unauthorizing port
Thu Apr 23 20:28:59 2015 daemon.info hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.11: disassociated
Thu Apr 23 20:28:59 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-DISASSOCIATE.indication(84:38:38:0f:15:94, 8)
Thu Apr 23 20:28:59 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-DELETEKEYS.request(84:38:38:0f:15:94)
Thu Apr 23 20:29:00 2015 daemon.info hostapd: wlan0: STA 84:38:38:0f:15:94 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Apr 23 20:29:00 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-DEAUTHENTICATE.indication(84:38:38:0f:15:94, 2)
Thu Apr 23 20:29:00 2015 daemon.debug hostapd: wlan0: STA 84:38:38:0f:15:94 MLME: MLME-DELETEKEYS.request(84:38:38:0f:15:94)

If you wait now for 10 minutes, then offline client B recovers and back online (has ping) with this log:

Thu Apr 23 21:12:41 2015 daemon.debug hostapd: wlan0: WPA rekeying GTK
Thu Apr 23 21:12:41 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 1/2 msg of Group Key Handshake
Thu Apr 23 21:12:41 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: EAPOL-Key timeout
Thu Apr 23 21:12:41 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 1/2 msg of Group Key Handshake
Thu Apr 23 21:12:42 2015 daemon.info hostapd: wlan1: STA f8:16:54:1c:95:c1 WPA: group key handshake completed (RSN)
Thu Apr 23 21:12:42 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: EAPOL-Key timeout
Thu Apr 23 21:12:42 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 1/2 msg of Group Key Handshake
Thu Apr 23 21:12:43 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: EAPOL-Key timeout
Thu Apr 23 21:12:43 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 1/2 msg of Group Key Handshake
Thu Apr 23 21:12:44 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: EAPOL-Key timeout
Thu Apr 23 21:12:44 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: WPA_PTK: sm->Disconnect
Thu Apr 23 21:12:44 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: event 3 notification
Thu Apr 23 21:12:44 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.1X: unauthorizing port
Thu Apr 23 21:12:44 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-DEAUTHENTICATE.indication(00:23:14:07:0e:3c, 2)
Thu Apr 23 21:12:44 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-DELETEKEYS.request(00:23:14:07:0e:3c)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: authentication OK (open system)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: event 0 notification
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-AUTHENTICATE.indication(00:23:14:07:0e:3c, OPEN_SYSTEM)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-DELETEKEYS.request(00:23:14:07:0e:3c)
Thu Apr 23 21:12:45 2015 daemon.info hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: authenticated
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: association OK (aid 2)
Thu Apr 23 21:12:45 2015 daemon.info hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.11: associated (aid 2)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-ASSOCIATE.indication(00:23:14:07:0e:3c)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c MLME: MLME-DELETEKEYS.request(00:23:14:07:0e:3c)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: event 1 notification
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 1/4 msg of 4-Way Handshake
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: received EAPOL-Key frame (2/4 Pairwise)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: sending 3/4 msg of 4-Way Handshake
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: received EAPOL-Key frame (4/4 Pairwise)
Thu Apr 23 21:12:45 2015 daemon.debug hostapd: wlan0: STA 00:23:14:07:0e:3c IEEE 802.1X: authorizing port
Thu Apr 23 21:12:45 2015 daemon.info hostapd: wlan0: STA 00:23:14:07:0e:3c WPA: pairwise key handshake completed (RSN)
Thu Apr 23 21:12:49 2015 daemon.info dnsmasq-dhcp[1762]: DHCPREQUEST(br-lan) 192.168.1.150 00:23:14:07:0e:3c 
Thu Apr 23 21:12:49 2015 daemon.info dnsmasq-dhcp[1762]: DHCPACK(br-lan) 192.168.1.150 00:23:14:07:0e:3c HP

[1] https://forum.openwrt.org/viewtopic.php?pid=277151#p277151

Vanav commented 9 years ago

Interface state at step 3, when only one "offline" client is left:

root@OpenWrt:/# iwinfo
wlan0     ESSID: "V2"
          Access Point: 00:25:9C:13:0D:0C
          Mode: Master  Channel: 11 (2.462 GHz)
          Tx-Power: 20 dBm  Link Quality: 70/70
          Signal: -38 dBm  Noise: -83 dBm
          Bit Rate: 54.0 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 11AB:2A55 11AB:0000 [Marvell 88W8864]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

wlan1     ESSID: "V2_5"
          Access Point: 00:25:9C:13:0D:0D
          Mode: Master  Channel: 36 (5.180 GHz)
          Tx-Power: 20 dBm  Link Quality: 63/70
          Signal: -47 dBm  Noise: -90 dBm
          Bit Rate: 162.0 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 11AB:2A55 11AB:0000 [Marvell 88W8864]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

root@OpenWrt:/# iwinfo wlan0 assoclist
00:23:14:07:0E:3C  -38 dBm / -85 dBm (SNR 47)  26210 ms ago
        RX: 48.0 MBit/s, MCS 0, 20MHz                    823 Pkts.
        TX: 54.0 MBit/s, MCS 0, 20MHz                    413 Pkts.

root@OpenWrt:/# iw dev wlan0 station dump
Station 00:23:14:07:0e:3c (on wlan0)
        inactive time:  45200 ms
        rx bytes:       49993
        rx packets:     755
        tx bytes:       40567
        tx packets:     407
        tx retries:     0
        tx failed:      0
        signal:         -40 dBm
        signal avg:     -39 dBm
        tx bitrate:     54.0 MBit/s
        rx bitrate:     48.0 MBit/s
        authorized:     yes
        authenticated:  yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no

root@OpenWrt:/# iw phy0 info
Wiphy phy0
        max # scan SSIDs: 4
        max scan IEs length: 2242 bytes
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
        Band 1:
                Capabilities: 0x6f
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX HT20 SGI
                        RX HT40 SGI
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT TX/RX MCS rate indexes supported: 0-23, 32
                VHT Capabilities (0x33981932):
                        Max MPDU length: 11454
                        Supported Channel Width: neither 160 nor 80+80
                        RX LDPC
                        short GI (80 MHz)
                        SU Beamformer
                        SU Beamformee
                        MU Beamformer
                        MU Beamformee
                        RX antenna pattern consistency
                        TX antenna pattern consistency
                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: 0 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: 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)
                        * 2472 MHz [13] (20.0 dBm)
                        * 2484 MHz [14] (disabled)
        valid interface combinations:
                 * #{ AP } <= 16, #{ managed } <= 1,
                   total <= 16, #channels <= 1
        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
yuhhaurlin commented 9 years ago

We can reproduce this one. Thanks.

Nihtilan commented 9 years ago

Any news on this?

yuhhaurlin commented 9 years ago

Should be fixed later.

JasonSwindle commented 9 years ago

Any update @yuhhaurlin ? :)

Vanav commented 9 years ago

I've tried latest trunk build and issue is still there. Do I need to update hostapd config?

# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r46069'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer r46069'
DISTRIB_TAINTS=''

# opkg list | grep -i mwlwifi
kmod-mwlwifi - 3.18.16+10.3.0.3-20150619-1

# cat /var/run/hostapd-phy0.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=DE
ieee80211d=1
hw_mode=g
channel=11

ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40]

interface=wlan0
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=password
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=24GHz
bridge=br-lan
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=xx:xx:xx:xx:xx:0c

# cat /var/run/hostapd-phy1.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=DE
ieee80211d=1
ieee80211h=1
hw_mode=a
channel=36

ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][SU-BEAMFORMER][SU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC1][MAX-MPDU-7991][MAX-A-MPDU-LEN-EXP7]

interface=wlan1
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=password
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=5GHz
bridge=br-lan
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=xx:xx:xx:xx:xx:0d
yuhhaurlin commented 9 years ago

Thanks for your information. This version had been tested with 8897 and this problem is gone. We will check it on 8864.

Chadster766 commented 9 years ago

Which router has chip 8897? Why wouldn't you fix 8864 which is the one everyone is concerned about?

gufus commented 9 years ago

Good question

Vanav commented 9 years ago

I've just tested r46118, nothing changes, issue is still there. Did you enabled encryption? Did you only use one radio frequency for all clients? Are you sure that there are no other clients connected during experiment?

# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r46118'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer r46118'
DISTRIB_TAINTS=''

# opkg list | grep -i mwlwifi
kmod-mwlwifi - 3.18.16+10.3.0.3-20150619-1

  Step 0. No clients on both radios.
# iwinfo wlan0 assoclist; iwinfo wlan1 assoclist
No station connected
No station connected

  Step 1. Client "94" connected to 5 GHz.
# iwinfo wlan1 assoclist
xx:xx:xx:xx:xx:94  -50 dBm / -89 dBm (SNR 39)  150 ms ago
        RX: 24.0 MBit/s, MCS 0, 20MHz                    236 Pkts.
        TX: 324.0 MBit/s, MCS 0, 40MHz                   133 Pkts.

  Step 2. Client "3C" connected to 5 GHz.
# iwinfo wlan1 assoclist
xx:xx:xx:xx:xx:94  -50 dBm / -89 dBm (SNR 39)  510 ms ago
        RX: 24.0 MBit/s, MCS 0, 20MHz                    357 Pkts.
        TX: 324.0 MBit/s, MCS 0, 40MHz                   203 Pkts.

xx:xx:xx:xx:xx:3C  -55 dBm / -89 dBm (SNR 34)  400 ms ago
        RX: 54.0 MBit/s, MCS 0, 20MHz                     73 Pkts.
        TX: 54.0 MBit/s, MCS 0, 20MHz                     31 Pkts.

  Step 3. Client "94" disconnected. Client "3C" is left associated,
  but without ping to router, notice 45020 ms inactive time.
# iwinfo wlan1 assoclist
xx:xx:xx:xx:xx:3C  -62 dBm / -89 dBm (SNR 27)  45020 ms ago
        RX: 48.0 MBit/s, MCS 0, 20MHz                    300 Pkts.
        TX: 54.0 MBit/s, MCS 0, 20MHz                     67 Pkts.
jdm13 commented 9 years ago

hello if you change encyption from CCMP to TKIP you will not have the issue..

but you will lose speed .. the maximun speed will 64 or 54

JW0914 commented 9 years ago

TKIP is not secure in the slightest, is as vulnerable as WEP, and should NOT be used,

jdm13 commented 9 years ago

yes but ... for temporary fix is ok ..( at my situration its coffee shop everyone know the pass) and maybe its help devs .. to find it ..

JW0914 commented 9 years ago

For a public AP/Network, sure... but if utilizing it on a private network temporarily for troubleshooting, stringent iptables rules should be be employed to protect the LAN while TKIP is being used temporarily (failing to do so leaves you wide open to the possibility of your network being compromised).

Vanav commented 9 years ago

I've just tested:

        option encryption 'psk+tkip'

Issue is still there, makes no difference for me.

jdm13 commented 9 years ago

thats is strange .... with CCMP i had issue after 7 hours ( with new rc2 and olders ) .. with tkip from 23 april none... i reboot the system every 3 hours ... but that isnt count at issues

config wifi-device 'radio0' option type 'mac80211' option hwmode '11g' option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0' option country 'DE' option txpower '20' option channel '11' option htmode 'HT20'

config wifi-iface option device 'radio0' option network 'lan' option mode 'ap' option key '0123456789' option ssid '**'
option encryption 'psk+tkip'

config wifi-device 'radio1' option type 'mac80211' option channel '36' option hwmode '11a' option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0' option htmode 'VHT80' option country 'DE' option txpower '20'

config wifi-iface option device 'radio1' option network 'lan' option mode 'ap' option ssid '*****' option key '0123456789' option encryption 'psk+tkip'

with those settings iam from 23 april . without lock up ( only slow net ) and at day i have 250+ clients ..

Chadster766 commented 9 years ago

@jdm13 you don't seem to understand the issue. With 250+ clients this issue would never occur.

Vanav commented 9 years ago

This issue is not about lockup, but about wireless clients disconnect. Lockup issue is #21.

jdm13 commented 9 years ago

@Chadster766 this happens only early at morning when the shop open .. never at middle of day ( at morning they are one or two .. or 3 .. :/ i dotn know iam sleeping ... ) @Vanav now iam confused .. its a bit the same ...

Vanav commented 9 years ago

@jdm13, #20 - router stays online, most clients have connection, but some clients randomly disconnect. Affected clients should manually reconnect to router.

21 - router randomly halts, no connection, all clients loose connection. The only recovery is router power reset.

Chadster766 commented 9 years ago

@Vanav doesn't it recover if a second device connects\reconnects? I had thought it did.

Vanav commented 9 years ago

@Chadster766, you're right, I've just simplified. Two ways to recover: 1) disconnected client reconnects (manually or re-key), 2) last disconnected client connects back.

nightwend commented 9 years ago

@Vanav You are right. It's not fixed. It's still occur if I switch client more times.

Chadster766 commented 9 years ago

Can we get an update on this issue for the WRT1900AC V1 please?

JW0914 commented 9 years ago

Have users who've experienced this tried RC2?

Vanav commented 9 years ago

I have tried trunk before RC2, and trunk after RC2, issue reproduces all the times. I don't expect that RC2 contains code that has not appeared before in trunk. I think anyone with RC2 version can reproduce this issue following simple steps.

JW0914 commented 9 years ago

I cannot reproduce the results on RC2, which is why I asked...

Also, RC2 obviously contains different code than trunk... For example, 5gHz radio in trunk isn't functioning properly, whereas it functions fine in RC2.

Vanav commented 9 years ago

Show your /etc/config/wireless. Did you enabled encryption? Did you only use one radio frequency for all clients? Are you sure that there are no other clients connected during experiment?

JW0914 commented 9 years ago 
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
option channel '6'
option country 'US'
option htmode 'HT20'
option txpower '20'

config wifi-iface
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid '----'
option hidden '1'
option encryption 'psk2+ccmp'
option key '----'
option macfilter 'allow'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'

config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
option htmode 'VHT80'
option country 'US'
option channel '157'
option distance '50'
option txpower '25'

config wifi-iface
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid '----'
option hidden '1'
option encryption 'psk2+ccmp'
option key '----'
option macfilter 'allow'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
list maclist '----'
Chadster766 commented 9 years ago

I will double check right now as well with RC2.

Chadster766 commented 9 years ago

Ok I triple checked with WRT1900AC V1 OpenWRT RC2 and issue #20 is not fixed. It's super easy to replicate since it's exactly the same as was reproduced before.

Wireless Overview

Marvell 88W8864 802.11bgn (radio0) Channel: 11 (2.462 GHz) | Bitrate: 130 Mbit/s

100% SSID: OpenWrt | Mode: Master BSSID: 00:25:9C:13:35:4A | Encryption: WPA2 PSK (CCMP)

Marvell 88W8864 802.11nac (radio1) Channel: 36 (5.180 GHz) | Bitrate: ? Mbit/s

0% SSID: OpenWrt50 | Mode: Master BSSID: 00:25:9C:13:35:4B | Encryption: WPA2 PSK (CCMP)

JW0914 commented 9 years ago

I never said it was fixed... just that I can't replicate it.

Chadster766 commented 9 years ago

The most resent commit to the wireless does says it's fixed but it obviously isn't for the WRT1900AC V1:

Commit mwlwifi driver 10.3.0.3 …

  1. Modified the code in order to be accepted by linux wireless.
  2. Let Tx thread be more modularized.
  3. Fixed issue #20.

Note: Please check hostapd sample configuration files to know current setting for vht_capab.

Signed-off-by: David Lin dlin@marvell.com

DavidMcWRT commented 9 years ago

@yuhhaurlin

yuhhaurlin commented 17 days ago: Thanks for your information. This version had been tested with 8897 and this problem is gone. We will check it on 8864.

Any news on this?!

OpenWRT CC RC3 must be due soon and it would be nice to have this issue fixed!

yuhhaurlin commented 9 years ago

Will check it later.

gufus commented 9 years ago

Sounds good …

From: yuhhaurlin [mailto:notifications@github.com] Sent: Tuesday, July 07, 2015 5:50 PM To: kaloz/mwlwifi Cc: gufus Subject: Re: [mwlwifi] Wireless goes offline if only one client is left connected (#20)

Will check it later.

— Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/20#issuecomment-119376098 . https://github.com/notifications/beacon/AIMiJ6_vUneq_9n6zkau2NEsipHO6Im4ks5obF0wgaJpZM4EgoFX.gif

thagabe commented 9 years ago

Hopefully sooner rather than later. I've moved to McWRT (I know i know) but it is extremely solid and no hang ups.

sunchar commented 9 years ago

This issue is really annoying. I have not TTL cable connected to router for diagnosis, but always get disconnected if i'm the last one connected to WiFi. If I can help doing some test, just tell. Thanks!

DavidMcWRT commented 9 years ago

@yuhhaurlin yuhhaurlin

yuhhaurlin commented 7 days ago Will check it later.

Any news?!

Please note this is not, as some seem to think, an issue restricted to Apple devices. I can trigger it with (just) an Android phone and Windows laptop.

sunchar commented 9 years ago

@DavidMcWRT

Same situation here.

kholbrook-inmotion commented 9 years ago

Ditto. This is the one major issue we currently have with the build.

@DavidMcWRT Is the wifi driver the major difference between the trunk CC build and the previous McWRT builds? As others have noted the older McWRT build was more stable with wifi.

thagabe commented 9 years ago

@kholbrook-inmotion McWRT was based on AA (Attitude Adjustment) which is much older code base than the developing CC (Chaos Calmer) an so it does not receive the latest security packages and what not. As far as I can remember McWRT is an off branch development of AA, BB's development was much buggier and thus abandoned, where @DavidMcWRT and mmilburn "ported" code from hostapd and adapted the code from a similar open source wireless device from Marvel.

DavidMcWRT commented 9 years ago

@sunchar @kholbrook-inmotion Thanks for reporting you're also encountering this problem.

@thagabe It was @Chadster766 who put all the pieces together to create McWRT; my username was just a nod to his project. Before that we only had AA and BB builds from Linksys with binary drivers.

People were getting upset with Linksys for promising OpenWRT support with the WRT1900 but not delivering anything usable by the community, and it got to the stage that all Linksys could do was offer refunds to unhappy customers. Around that time an upstreamable wifi driver was finally released by Marvell, which is the one in CC now.

@yuhhaurlin I hope Marvell are able to fix these driver issues (notably this issue 20, and issue 21) soon, since it would be a shame now that we're so close to have users give up in frustration and return their products for something more usable/stable.

yuhhaurlin commented 9 years ago

Sorry. We try to modify the code to be accepted by Linux Wireless. We will check these problems soon.

DavidMcWRT commented 9 years ago

@yuhhaurlin Thanks for your reply.

Given that OpenWRT CC is now at RC3 stage, it would seem fairly urgent to try and resolve these issues as soon as possible.

Modification and clean up of code for mainline kernel would seem to me to be a more longer term (and lower priority) goal - and having it work BEFORE upstreaming it would also make sense too!

thagabe commented 9 years ago

@yuhhaurlin My question is why don't you guys work on a branched version of @kaloz 's master branch. That way it is improved with the community and pull requests can be used to merge code.

Edit: @yuhhaurlin I see! So you guys are trying to incorporate the code into the linux mainline kernel! That's great! I think that would really improve the development of the driver and make it much easier in terms of organization.

@DavidMcWRT right hahaha i forgot, it's been a long time.

@kholbrook-inmotion @DavidMcWRT is right @Chadster766 is the original developer of McWRT

kholbrook-inmotion commented 9 years ago

@yuhhaurlin Any updates? For our project, we are approaching the point where if the wifi driver is not stable we will have to switch hardware platforms. We like the hardware, but it has to work reliably. We specifically chose the WRT-1900AC based on claims by Linksys it was supporting the hardware with OpenWRT and still does, "Developed for use with OpenWRT". I just want to reiterate issues #20 and #21 are extremely important to be resolved soon for adoption of this hardware. It's been exciting to see this project move forward, even despite the rocky start, and we hope these issues will be addressed with v1 hardware soon.