Modify ↓

Opened 4 years ago

Closed 3 years ago

Last modified 18 months ago

#15320 closed defect (fixed)

TP-Link TL-WR941NDv3 stops accepting wireless clients

Reported by: clayman@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

TP-Link TL-WR941N/ND v3
OpenWrt Barrier Breaker r39930 / LuCI Trunk (svn-r9961)

After some uptime router suddenly drops all wireless connections and stops accepting new wireless connections. SSID remains visible. Cable connections work normal. Kernel log and system log show nothing unusual.

Restarting wireless by '/sbin/wifi' return router to normal functionality.

This problem always existed but raises more often after last few updates.

cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11ng'
        option path 'platform/ath9k'
        list ht_capab 'SHORT-GI-40'
        list ht_capab 'DSSS_CCK-40'
        option txpower '20'
        option htmode 'HT40-'
        option noscan '1'
        option country 'RU'
        option channel '8'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'underworld'
        option encryption 'psk2+ccmp'
        option key '**********************'

cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset

    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  3
      PLL RX Hang:  0
         MAC Hang: 199
     Stuck Beacon: 59
        MCI Reset:  0

cat /sys/kernel/debug/ieee80211/phy*/ath9k/interrupt

                   RX:     850106
                RXEOL:          2
                RXORN:          7
                   TX:    1176049
                TXURN:          0
                  MIB:          0
                RXPHY:          0
                RXKCM:          0
                 SWBA:    1662987
                BMISS:          0
                  BNR:          0
                  CST:      12860
                  GTT:          0
                  TIM:          0
               CABEND:          0
             DTIMSYNC:          0
                 DTIM:          0
               TSFOOR:          0
                  MCI:          0
             GENTIMER:          0
                TOTAL:    3609313
SYNC_CAUSE stats:
             Sync-All:          0
              RTC-IRQ:          0
              MAC-IRQ:          0
EEPROM-Illegal-Access:          0
          APB-Timeout:          0
    PCI-Mode-Conflict:          0
          HOST1-Fatal:          0
           HOST1-Perr:          0
       TRCV-FIFO-Perr:          0
          RADM-CPL-EP:          0
  RADM-CPL-DLLP-Abort:          0
   RADM-CPL-TLP-Abort:          0
    RADM-CPL-ECRC-Err:          0
     RADM-CPL-Timeout:          0
    Local-Bus-Timeout:          0
            PM-Access:          0
            MAC-Awake:          0
           MAC-Asleep:          0
     MAC-Sleep-Access:          0

Attachments (6)

SyslogCatchAll-2014-06-07.zip​ (439.7 KB) - added by clayman@… 4 years ago.
SyslogCatchAll-2014-06-07.zip
SyslogCatchAll-2014-06-08.zip​ (203.4 KB) - added by clayman@… 4 years ago.
SyslogCatchAll-2014-06-08.zip
SyslogCatchAll-2014-06-08-2.zip​ (390.1 KB) - added by clayman@… 4 years ago.
SyslogCatchAll-2014-06-08-2.zip
SyslogCatchAll-2014-06-12.zip​ (22.4 KB) - added by clayman@… 4 years ago.
SyslogCatchAll-2014-06-12.zip
SyslogCatchAll-2014-06-13.zip​ (61.6 KB) - added by clayman@… 4 years ago.
SyslogCatchAll-2014-06-13.zip
SyslogCatchAll-2014-06-13-2.zip​ (108.0 KB) - added by clayman@… 4 years ago.
SyslogCatchAll-2014-06-13-2.zip

Download all attachments as: .zip

Change History (65)

comment:1 Changed 4 years ago by anonymous

I got exactly the same problem with r39969 on the TL-WR1043ND.
No strange entries in the logs indeed..

comment:2 Changed 4 years ago by anonymous

Same problem here on TL-WR1043ND v1 running r39969.

One thing I did notice in the logs was that all connected clients where disconnected at the same time like this:

Sun Mar 22 20:54:30 2014 daemon.info hostapd: wlan0: STA so:me:ma:c0:00:00 IEEE 802.11: deauthenticated due to local deauth request
Sun Mar 22 20:54:30 2014 daemon.info hostapd: wlan0: STA so:me:ma:c0:00:01 IEEE 802.11: deauthenticated due to local deauth request
Sun Mar 22 20:54:30 2014 daemon.info hostapd: wlan0: STA so:me:ma:c0:00:02 IEEE 802.11: deauthenticated due to local deauth request
Sun Mar 22 20:54:30 2014 daemon.info hostapd: wlan0: STA so:me:ma:c0:00:03 IEEE 802.11: deauthenticated due to local deauth request

Those where the last wifi entries in the logs, hours before I logged in via ethernet to check up on the situation. The failing attempts to associate with the AP are not being logged at this log level.

I upgraded to r40004 and set the log level to 0. If it happens again I will report back here.

comment:3 Changed 4 years ago by anonymous

Problem still exists in r40004...

comment:4 Changed 4 years ago by mbielowicz@…

With r39585 (WDR3600 in AP mode, WPA2, HT20) i had 20Mbps wifi throughput from AP to clients and it was stable for a long time. Starting with r39928, the same hardware/configuration, wifi throughput badly drops an order of magnitude to 50-100Kbps. Additionaly when i'm browsing WWW there is 2-3 sec. delay after entering URL and moment when site starts loading. There were no such problems with r39585. Moreover, like it is noted above AP drops wifi connections frequently.

comment:5 Changed 4 years ago by anonymous

Can I help giving some debug information?
The router is barely usable now (r40004), I have to /sbin/wifi down && /sbin/wifi up every 3 hours!

comment:6 Changed 4 years ago by anonymous

Same as above here. Just happened again on r40004. Here is my config and an interesting log that shows what actually happened. I guess the more initiated (nbd?) can see what is going wrong here.

cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/ath9k'
	list ht_capab 'SHORT-GI-40'
	list ht_capab 'DSSS_CCK-40'
	option hwmode '11ng'
	option htmode 'HT20'
	option country 'NZ'
	option channel '6'
	option txpower '22'

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

cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset

    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  2
      PLL RX Hang:  0
         MAC Hang: 4593
     Stuck Beacon: 30
        MCI Reset:  0

cat /sys/kernel/debug/ieee80211/phy*/ath9k/interrupt

                   RX:    3834353
                RXEOL:          0
                RXORN:          0
                   TX:    1976041
                TXURN:          0
                  MIB:          0
                RXPHY:          0
                RXKCM:          0
                 SWBA:    8481140
                BMISS:          0
                  BNR:          0
                  CST:      11060
                  GTT:          0
                  TIM:          0
               CABEND:          0
             DTIMSYNC:          0
                 DTIM:          0
               TSFOOR:          0
                  MCI:          0
             GENTIMER:          0
                TOTAL:   14161782
SYNC_CAUSE stats:
             Sync-All:          0
              RTC-IRQ:          0
              MAC-IRQ:          0
EEPROM-Illegal-Access:          0
          APB-Timeout:          0
    PCI-Mode-Conflict:          0
          HOST1-Fatal:          0
           HOST1-Perr:          0
       TRCV-FIFO-Perr:          0
          RADM-CPL-EP:          0
  RADM-CPL-DLLP-Abort:          0
   RADM-CPL-TLP-Abort:          0
    RADM-CPL-ECRC-Err:          0
     RADM-CPL-Timeout:          0
    Local-Bus-Timeout:          0
            PM-Access:          0
            MAC-Awake:          0
           MAC-Asleep:          0
     MAC-Sleep-Access:          0

logread

...
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: WPA rekeying GTK
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: received EAPOL-Key frame (2/2 Group)
Mon Mar 24 22:36:33 2014 daemon.info hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: group key handshake completed (RSN)
Mon Mar 24 22:36:33 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: received EAPOL-Key frame (2/2 Group)
Mon Mar 24 22:36:33 2014 daemon.info hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: group key handshake completed (RSN)
Mon Mar 24 22:36:34 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: received EAPOL-Key frame (2/2 Group)
Mon Mar 24 22:36:34 2014 daemon.info hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: group key handshake completed (RSN)
Mon Mar 24 22:36:34 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: received EAPOL-Key frame (2/2 Group)
Mon Mar 24 22:36:34 2014 daemon.info hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: group key handshake completed (RSN)
Mon Mar 24 22:36:34 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: received EAPOL-Key frame (2/2 Group)
Mon Mar 24 22:36:34 2014 daemon.info hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: group key handshake completed (RSN)
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: WPA rekeying GTK
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:33 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx IEEE 802.1X: did not Ack EAPOL-Key frame (broadcast index=4)
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:34 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx IEEE 802.1X: did not Ack EAPOL-Key frame (broadcast index=4)
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:35 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx IEEE 802.1X: did not Ack EAPOL-Key frame (broadcast index=4)
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: sending 1/2 msg of Group Key Handshake
Mon Mar 24 22:46:36 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx IEEE 802.1X: did not Ack EAPOL-Key frame (broadcast index=4)
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: WPA_PTK: sm->Disconnect
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx WPA: event 3 notification
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx IEEE 802.1X: unauthorizing port
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: WPA_PTK: sm->Disconnect
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx WPA: event 3 notification
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx IEEE 802.1X: unauthorizing port
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: WPA_PTK: sm->Disconnect
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx WPA: event 3 notification
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx IEEE 802.1X: unauthorizing port
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: WPA_PTK: sm->Disconnect
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx WPA: event 3 notification
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx IEEE 802.1X: unauthorizing port
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx MLME: MLME-DEAUTHENTICATE.indication(04:f7:e4:72:xx:xx, 2)
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:f7:e4:72:xx:xx MLME: MLME-DELETEKEYS.request(04:f7:e4:72:xx:xx)
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: EAPOL-Key timeout
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: WPA_PTK: sm->Disconnect
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx WPA: event 3 notification
Mon Mar 24 22:46:37 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx IEEE 802.1X: unauthorizing port
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx MLME: MLME-DEAUTHENTICATE.indication(14:10:9f:d2:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx MLME: MLME-DELETEKEYS.request(14:10:9f:d2:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx MLME: MLME-DEAUTHENTICATE.indication(2c:a8:35:2f:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx MLME: MLME-DELETEKEYS.request(2c:a8:35:2f:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx MLME: MLME-DEAUTHENTICATE.indication(14:10:9f:d2:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 14:10:9f:d2:xx:xx MLME: MLME-DELETEKEYS.request(14:10:9f:d2:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx MLME: MLME-DEAUTHENTICATE.indication(58:b0:35:70:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx MLME: MLME-DELETEKEYS.request(58:b0:35:70:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx MLME: MLME-DEAUTHENTICATE.indication(2c:a8:35:2f:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 2c:a8:35:2f:xx:xx MLME: MLME-DELETEKEYS.request(2c:a8:35:2f:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx MLME: MLME-DEAUTHENTICATE.indication(58:b0:35:70:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 58:b0:35:70:xx:xx MLME: MLME-DELETEKEYS.request(58:b0:35:70:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx MLME: MLME-DEAUTHENTICATE.indication(04:1e:64:6e:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx MLME: MLME-DELETEKEYS.request(04:1e:64:6e:xx:xx)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx MLME: MLME-DEAUTHENTICATE.indication(04:1e:64:6e:xx:xx, 2)
Mon Mar 24 22:46:39 2014 daemon.debug hostapd: wlan0: STA 04:1e:64:6e:xx:xx MLME: MLME-DELETEKEYS.request(04:1e:64:6e:xx:xx)
Mon Mar 24 22:46:42 2014 daemon.info hostapd: wlan0: STA 04:f7:e4:72:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 24 22:46:42 2014 daemon.info hostapd: wlan0: STA 14:10:9f:d2:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 24 22:46:42 2014 daemon.info hostapd: wlan0: STA 2c:a8:35:2f:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 24 22:46:42 2014 daemon.info hostapd: wlan0: STA 58:b0:35:70:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 24 22:46:42 2014 daemon.info hostapd: wlan0: STA 04:1e:64:6e:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 24 22:56:33 2014 daemon.debug hostapd: wlan0: WPA rekeying GTK
Mon Mar 24 23:06:33 2014 daemon.debug hostapd: wlan0: WPA rekeying GTK
Mon Mar 24 23:16:33 2014 daemon.debug hostapd: wlan0: WPA rekeying GTK
...

What we see is a successful group rekey event at 22:36:33 (and more before that), but then the next group rekey event at 22:46:33 initiates a series of events that kicks all clients out, and prevents them from reconnecting thereafter. 9 seconds later, at 22:46:42, the AP is effectively dead. It's still rekeying every 10 minutes, and the SSID is being broadcast, but clients trying to connect fail and don't show here in the log.

comment:7 Changed 4 years ago by anonymous

same problem here TL-WR1043ND v1.8, when wifi (AP) is in idle mode without connected clients everything seems to be ok, but in storm traffic driver hangs after short time.

comment:8 Changed 4 years ago by anonymous

Maybe nbd can comment on this please?

comment:9 Changed 4 years ago by nbd

Please try copying ​http://nbd.name/950-test.patch to package/kernel/mac80211/patches (package/mac80211/patches on AA) and see if it helps.

comment:10 Changed 4 years ago by nbd

The patch has been committed. Here's another one that might improve things further, please test: ​​http://nbd.name/950-test2.patch

comment:11 Changed 4 years ago by clayman@…

First patch (​http://nbd.name/950-test.patch) doesn't solve the problem.

comment:12 Changed 4 years ago by clayman@…

TP-Link TL-WR941N/ND v3
OpenWrt Barrier Breaker r40504 + 950-test2.patch

AP is dead after 2 days of uptime.

comment:13 Changed 4 years ago by clayman@…

TP-Link TL-WR941N/ND v3
OpenWrt Barrier Breaker r40504 + 950-test2.patch

Positively, second patch extends uptime of AP to 2-3 days, but not enough to make it stable.

comment:14 Changed 4 years ago by nbd

please try copying ​http://nbd.name/950-test3.patch to package/kernel/mac80211/patches, rebuild and test again.

comment:15 Changed 4 years ago by clayman@…

r40604.
First time AP died after 2 hours of uptime, second time after 20 hours of uptime.

comment:16 Changed 4 years ago by luminoso@…

I also have this problem. Is there anyway I can help? r40585

cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11ng'
        option path 'platform/ath9k'
        list ht_capab 'SHORT-GI-40'
        list ht_capab 'DSSS_CCK-40'
        option country 'PT'
        option channel '11'
        option htmode 'HT40-'
        option txpower '18'

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'Mia'
        option encryption 'psk2+ccmp'
        option key '141631f77abc'
        option network 'lan'

I already started hostapd inside a screen to see what's happening this was the last lines:

wlan0: STA e8:94:f6:18:d6:66 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
wlan0: STA e8:94:f6:18:d6:66 MLME: MLME-DEAUTHENTICATE.indication(e8:94:f6:18:d6:66, 2)
wlan0: STA e8:94:f6:18:d6:66 MLME: MLME-DELETEKEYS.request(e8:94:f6:18:d6:66)
wlan0: AP-STA-DISCONNECTED 04:46:65:52:36:3d
wlan0: STA 04:46:65:52:36:3d IEEE 802.11: disassociated due to inactivity
wlan0: STA 04:46:65:52:36:3d MLME: MLME-DISASSOCIATE.indication(04:46:65:52:36:3d, 4)
wlan0: STA 04:46:65:52:36:3d MLME: MLME-DELETEKEYS.request(04:46:65:52:36:3d)
wlan0: STA 04:46:65:52:36:3d IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
wlan0: STA 04:46:65:52:36:3d MLME: MLME-DEAUTHENTICATE.indication(04:46:65:52:36:3d, 2)
wlan0: STA 04:46:65:52:36:3d MLME: MLME-DELETEKEYS.request(04:46:65:52:36:3d)
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
wlan0: WPA rekeying GTK
(... and a few more...)

dmesg last lines:

[55133.360000] device wlan0 left promiscuous mode
[55133.360000] br-lan: port 2(wlan0) entered disabled state

[35877.660000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x00028cc0
[35877.670000] ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up

luci system log last lines:

Thu May  8 12:22:03 2014 daemon.info hostapd: wlan0: STA 04:46:65:52:36:3d WPA: group key handshake completed (RSN)
Thu May  8 12:25:10 2014 daemon.info hostapd: wlan0: STA e8:94:f6:18:d6:66 IEEE 802.11: disconnected due to excessive missing ACKs
Thu May  8 12:25:40 2014 daemon.info hostapd: wlan0: STA e8:94:f6:18:d6:66 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu May  8 12:28:33 2014 daemon.info hostapd: wlan0: STA 04:46:65:52:36:3d IEEE 802.11: disassociated due to inactivity
Thu May  8 12:28:34 2014 daemon.info hostapd: wlan0: STA 04:46:65:52:36:3d IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu May  8 18:30:30 2014 authpriv.info dropbear[1823]: Child connection from 192.168.1.100:44103
Thu May  8 18:30:40 2014 authpriv.notice dropbear[1823]: Password auth succeeded for 'root' from 192.168.1.100:44103

comment:17 Changed 4 years ago by nbd

please try the current version

comment:18 Changed 4 years ago by nbd

  • Resolution set to no_response
  • Status changed from new to closed

comment:19 Changed 4 years ago by clayman@…

  • Resolution no_response deleted
  • Status changed from closed to reopened

TP-Link TL-WR941N/ND v3
OpenWrt Barrier Breaker r40823

Still the same symptoms after 40 hours of uptime.

It seems the problem is connected to ANI, because with disabled ANI uptime was 10 days without any problems until I upgraded from r40716 to r40823 and enabled ANI again.

comment:20 follow-up: Changed 4 years ago by luminoso@…

running r40777 with 5 days uptime. Yet is too soon to tell if it is solved.
What's ANI, clayman?

comment:21 in reply to: ↑ 20 Changed 4 years ago by anonymous

Replying to luminoso@…:

running r40777 with 5 days uptime. Yet is too soon to tell if it is solved.
What's ANI, clayman?

ANI is Adaptive (Ambient) Noise Immunity.

Currently running r40823 with disabled ANI on TP-Link TL-WR941N/ND v3, uptime is more than 5 days, no problems at all except ticket #14202.

I don't know if it does make sense to test current version with enabled ANI.

comment:22 Changed 4 years ago by luminoso@…

Ok, after 12 days uptime it started rejecting new clients again. r40777

comment:23 Changed 4 years ago by nbd

please update again, more fixes were added.

comment:24 Changed 4 years ago by clayman@…

TP-Link TL-WR941N/ND v3

r41020 with ANI enabled is dead after 40 minutes of average load.

Before, r40823 with ANI disabled was stable more than 10 days.

comment:25 follow-up: Changed 4 years ago by nbd

I could finally reproduce some ANI issues in my tests. The ANI related stability issue should hopefully be fixed in r41028, please test.

comment:26 in reply to: ↑ 25 Changed 4 years ago by clayman@…

Replying to nbd:

I could finally reproduce some ANI issues in my tests. The ANI related stability issue should hopefully be fixed in r41028, please test.

Nope, r41029 is dead after 2 hours.

comment:27 follow-up: Changed 4 years ago by nbd

I'm beginning to suspect that it might not be an ANI issue, I think disabling ANI via debugfs also disables a bunch of other periodic calibrations.
Please try this patch without disabling ANI via debugfs: ​http://nbd.name/950-ani_check.patch

comment:28 in reply to: ↑ 27 Changed 4 years ago by clayman@…

Replying to nbd:

I'm beginning to suspect that it might not be an ANI issue, I think disabling ANI via debugfs also disables a bunch of other periodic calibrations.
Please try this patch without disabling ANI via debugfs: ​http://nbd.name/950-ani_check.patch

Yep, r41037+patch, ANI enabled, AP is dead after 8 hours.

comment:29 follow-up: Changed 4 years ago by nbd

Please ensure that CONFIG_PACKAGE_ATH_DEBUG is set in your config, boot up the system, and run this command:

uci set system.@system[0].log_size=256
/etc/init.d/log restart
echo 0x4409 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug

Then wait for wifi to die and give me the full output of 'logread' afterwards.

Thanks

comment:30 Changed 4 years ago by anonymous

I use a snapshot build from downloads.openwrt.org/snapshots/trunk/ar71xx. Is CONFIG_PACKAGE_ATH_DEBUG set in those builds?

Aka can I use the above procedure to help?

comment:31 Changed 4 years ago by nbd

that option is not set by default in the snapshot builds.

Changed 4 years ago by clayman@…

SyslogCatchAll-2014-06-07.zip

comment:32 in reply to: ↑ 29 Changed 4 years ago by clayman@…

Replying to nbd:

Please ensure that CONFIG_PACKAGE_ATH_DEBUG is set in your config, boot up the system, and run this command:

uci set system.@system[0].log_size=256
/etc/init.d/log restart
echo 0x4409 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug

Then wait for wifi to die and give me the full output of 'logread' afterwards.

Thanks

Ok. I attached archive with log to the ticket.
Last ping reply was received from AP at 21:35:30.
Hope it will help.

comment:33 Changed 4 years ago by nbd

Thanks, that log does help. IQ mismatch calibration looks fine. It appears to me that the failure is triggered by a hiccup in noise floor calibration. I will review the code to see if I can make that part more reliable.

comment:34 Changed 4 years ago by nbd

Here's a test patch that I wrote based on what I saw in the log, please test:
​http://nbd.name/950-nfcal_fix.patch

If it doesn't crash, please check the log if the message "NF calibration returned invalid values" appears, and let me know when it does.

Thanks again

Changed 4 years ago by clayman@…

SyslogCatchAll-2014-06-08.zip

comment:35 Changed 4 years ago by clayman@…

Another log fragment attached.
Last ping at 06:09:05.

comment:36 Changed 4 years ago by nbd

Found a bug in noise floor calibration, here's another patch: ​http://nbd.name/950-nfcal_skip.patch

Please watch for the log message "NF calibration still pending, skip reading results"

Changed 4 years ago by clayman@…

SyslogCatchAll-2014-06-08-2.zip

comment:37 Changed 4 years ago by clayman@…

One more log fragment attached.
Time of death 23:48:06.

comment:38 Changed 4 years ago by nbd

please try r41113

Changed 4 years ago by clayman@…

SyslogCatchAll-2014-06-12.zip

comment:39 Changed 4 years ago by clayman@…

r41147, last ping at 02:23:55.
Log attached.

comment:40 Changed 4 years ago by nbd

In the latest log it looks like the symptoms changed a bit. I've made further improvements to calibration handling in r41156 - now the noise floor calibration and IQ calibration should not interfere with each other anymore - please test.

Changed 4 years ago by clayman@…

SyslogCatchAll-2014-06-13.zip

comment:41 Changed 4 years ago by clayman@…

Ok, r41156.

By now AP is functioning, but there was wifi blackout from 03:04:40 till 03:04:56 (disconnected due to excessive missing ACKs). I found this interesting because of log records in this time interval.

Also, calibration error appears in debug info as intended:

# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang: 11
      PLL RX Hang:  0
         MAC Hang: 897
     Stuck Beacon:  1
        MCI Reset:  0
Calibration error:  1

Changed 4 years ago by clayman@…

SyslogCatchAll-2014-06-13-2.zip

comment:42 Changed 4 years ago by clayman@…

In previously uploaded log

2014-06-13 19:00:32	Local7.Debug	192.168.1.1	hostapd: wlan0: STA cc:b2:55:04:0f:c4 IEEE 802.11: disconnected due to excessive missing ACKs

It seems after that NF and IQ calibration stopped completely.
Needless to say, no one can connect to AP anymore.

comment:43 Changed 4 years ago by anonymous

any news?

comment:44 Changed 4 years ago by anonymous

Yes, this looked like an interesting development. Any progress?

comment:45 Changed 4 years ago by nctech-openwrt

My OpenWRT-based router also suffers from this problem. I can confirm this problem still exists in r41163.

Problem:
Wireless devices connect, work for some random time ranging from a few seconds up to about one hour, then disconnect and can not get reconnected. The log indicates a local deauth request as the reason for disconnection. After being disconnected, the affected clients can not reconnect until the router is rebooted.

Device information:
Model TP-Link TL-WR1043N/ND v2
Firmware Version OpenWrt Barrier Breaker r41163 / LuCI Trunk (svn-r10288)
Kernel Version 3.10.36

My OpenWRT router uses WPA2-PSK with CCMP

logread message snip:
Mon Jun 30 01:49:09 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Mon Jun 30 01:49:09 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Mon Jun 30 01:49:14 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Mon Jun 30 01:49:14 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Mon Jun 30 01:49:22 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request
Mon Jun 30 01:49:38 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Mon Jun 30 01:49:38 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Mon Jun 30 01:49:46 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request
Mon Jun 30 01:50:07 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Mon Jun 30 01:50:07 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Mon Jun 30 01:50:15 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request
Mon Jun 30 01:50:45 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Mon Jun 30 01:50:45 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Mon Jun 30 01:50:53 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request

My client devices that are affected and can not re-connect until router reboot:
Linksys WRT54GL v1.1 acting as wireless client (using dd-wrt 24)
Motorola Moto G mobile phone (using stock Android 4.4.3)

My client devices that do not seem to be affected and can still connect and use wifi:
Acer D250 netbook (running Xubuntu Linux 12.04)
Samsung Galaxy Q (running "Samsung" Android 2.4)

I am willing to assist in troubleshooting and testing. I have a reasonable level of experience with getting around the devices and command-lines, but I wouldn't call myself an OpenWRT expert. I am quite familiar with SSH/Telnet and various communications protocols. I don't know how to apply a patch file under OpenWRT, but if someone points me to a how-to doc, I'm sure I could manage. I recently bought this router as a potential upgrade to using dd-wrt on a second Linksys WRT54GL, to have faster gigabit ethernet and 300Mbit wireless - and Murphy's law dictated that I choose a model that is a little quirky with OpenWRT.. hehe. I'm sure it will come around because OpenWRT is a great project, and I'll do what I can.

Just let me know what kind of info you need me to provide.

Cheers,
Mike

Last edited 4 years ago by nctech-openwrt (previous) (diff)

comment:46 Changed 4 years ago by thelists@…

Just commented over on #12372, but I can confirm that I too am still seeing the issue on an TL-WDR4300 on BB r41391.

comment:47 Changed 4 years ago by anonymous

This looks a lot like:http://www.bufferbloat.net/issues/442#note-16 - when it happens do you see one of the hardware queues stuck with a lot of pending frames?

comment:48 Changed 4 years ago by nbd

please test r41673

comment:49 Changed 4 years ago by clayman@…

r41702
Still drops clients due to excessive missing acks (traffic is low though). Clients can reconnect.

comment:50 Changed 4 years ago by nbd

please try r41815

comment:51 Changed 4 years ago by clayman@…

r41815, very light load

Sat Jul 26 03:24:06 2014 daemon.info hostapd: wlan0: STA cc:b2:55:04:0f:c4 IEEE 802.11: disconnected due to excessive missing ACKs
Sat Jul 26 03:24:08 2014 daemon.info hostapd: wlan0: STA cc:b2:55:04:0f:c4 IEEE 802.11: authenticated
Sat Jul 26 03:24:08 2014 daemon.info hostapd: wlan0: STA cc:b2:55:04:0f:c4 IEEE 802.11: associated (aid 1)
Sat Jul 26 03:24:08 2014 daemon.info hostapd: wlan0: STA cc:b2:55:04:0f:c4 WPA: pairwise key handshake completed (RSN)

2014/07/26 03:24:00.747 : Reply[4937] from 192.168.1.1: bytes=64 time=2.0 ms TTL=64
2014/07/26 03:24:01.749 : Reply[4938] from 192.168.1.1: bytes=64 time=2.1 ms TTL=64
2014/07/26 03:24:02.751 : Reply[4939] from 192.168.1.1: bytes=64 time=1.9 ms TTL=64
2014/07/26 03:24:03.755 : Reply[4940] from 192.168.1.1: bytes=64 time=2.1 ms TTL=64
2014/07/26 03:24:05.104 : Reply[4941] from 192.168.1.1: bytes=64 time=348.5 ms TTL=64
2014/07/26 03:24:06.805 : Reply[4942] from 192.168.1.1: bytes=64 time=699.8 ms TTL=64
2014/07/26 03:24:07.807 : Reply[4943] from 192.168.1.1: bytes=64 time=437.9 ms TTL=64
2014/07/26 03:24:10.246 : 192.168.1.1: request timed out
2014/07/26 03:24:10.636 : Reply[4945] from 192.168.1.1: bytes=64 time=391.1 ms TTL=64
2014/07/26 03:24:11.684 : Reply[4946] from 192.168.1.1: bytes=64 time=45.3 ms TTL=64
2014/07/26 03:24:12.687 : Reply[4947] from 192.168.1.1: bytes=64 time=1.8 ms TTL=64
2014/07/26 03:24:14.687 : 192.168.1.1: request timed out
2014/07/26 03:24:15.688 : 192.168.1.1: request timed out
2014/07/26 03:24:16.688 : 192.168.1.1: request timed out
2014/07/26 03:24:16.984 : Reply[4951] from 192.168.1.1: bytes=64 time=295.9 ms TTL=64
2014/07/26 03:24:17.987 : Reply[4952] from 192.168.1.1: bytes=64 time=1.6 ms TTL=64
2014/07/26 03:24:18.989 : Reply[4953] from 192.168.1.1: bytes=64 time=1.5 ms TTL=64
2014/07/26 03:24:19.995 : Reply[4954] from 192.168.1.1: bytes=64 time=5.2 ms TTL=64
2014/07/26 03:24:20.998 : Reply[4955] from 192.168.1.1: bytes=64 time=1.5 ms TTL=64

# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang: 36
     Stuck Beacon:  5
        MCI Reset:  0
Calibration error:  0

comment:52 Changed 4 years ago by anonymous

WR1043ND v1 running r41824 seems to be holding up fine. Thanks Felix for your hard work! :)

So no hangs or obvious problems, but I did spot this in the logs. I've never seen AR_CR, AR_DIAG_SW or DMADBG_7 before.

# dmesg
...
[26287.370000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x000286c0
[26287.380000] ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up

# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang: 43
     Stuck Beacon:  1
        MCI Reset:  0
Calibration error:  0

comment:53 Changed 4 years ago by anonymous

Addon to last post: my other WR1043ND v1 has more Stuck Beacons, but nothing in dmesg, so the single stuck beacon above might have nothing to do with the single event in dmesg.

# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang: 143
     Stuck Beacon: 20
        MCI Reset:  0
Calibration error:  0

comment:54 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:55 Changed 3 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:56 Changed 3 years ago by nctech-openwrt

I have a couple of comments to add..

  1. First, thank-you for all your hard work. I installed r42625 on my TP-Link TL-WR1043ND v2.1 today and the wireless finally looks stable. Many thanks!
  1. I thought.. hey, it might be fun to try Chaos, so I installed Chaos r43006 and .. to my surprise, the wireless was flaky again, disconnecting my clients, requiring a reboot of the router to get them connected after only a few minutes of operation. So, I just wanted to say so, in case your hard work didn't get carried over into the latest code stream. I'm not sure how that works, but thought you might like to know.

I flashed back to the latest stable r42625 and it's working well.

UPDATE: It seems that r42625 is still dropping my wireless clients after a while. However, I went into the wifi settings and dialed-back the power from 1000mW to 500mW(501mW) and my clients hooked back up right away. Will continue to test. I have not reopened the ticket, on purpose, as I'm not sure yet.

Sincere thanks,
Mike

Last edited 3 years ago by nctech-openwrt (previous) (diff)

comment:57 Changed 3 years ago by nbd

Thanks for reporting. I believe the stability issue you're referring to has been fixed in r43011, so if you try latest Chaos Calmer it should be stable.

comment:58 Changed 3 years ago by nctech-openwrt

I have flashed the latest Chaos r43031. I think it's a little worse than before, as I can't connect to it at all from some of my wireless client devices. After the client associates, the connection is immediately dropped by local deauth.

root@openwrt:~# logread -f
Thu Oct 23 22:07:27 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Thu Oct 23 22:07:27 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 3)
Thu Oct 23 22:07:35 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request
Thu Oct 23 22:08:04 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Thu Oct 23 22:08:04 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 3)
Thu Oct 23 22:08:12 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request

This behavior continues until I stop the client from trying to connect. Rebooting the router does not resolve it, even temporarily.

root@openwrt:~# uptime
 22:22:44 up 3 min,  load average: 0.99, 0.41, 0.16
root@openwrt:~# logread -f
Thu Oct 23 22:23:13 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Thu Oct 23 22:23:14 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Thu Oct 23 22:23:18 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: authenticated
Thu Oct 23 22:23:18 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: associated (aid 1)
Thu Oct 23 22:23:26 2014 daemon.info hostapd: wlan0-1: STA 34:bb:26:97:59:05 IEEE 802.11: deauthenticated due to local deauth request

I can successfully connect the same wireless client to an older model router running 12.09, r36088.

What kind of further information should I provide to assist?

comment:59 Changed 18 months ago by anonymous

Same problem with 15.05.01 and td-1043nd v3
I have tried any wireless option with LuCI without success

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

Attachments ↑ Description ↑
 
Note: See TracTickets for help on using tickets.