Modify

Opened 7 years ago

Closed 5 years ago

Last modified 4 years ago

#9882 closed defect (fixed)

N mode still unusable on ath9k

Reported by: Slowmo <slowmo@…> Owned by: nbd
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Backfire 10.03.1 RC5
Keywords: ath9k HT20 HT40 Cc: maddes

Description

Just upgraded to Backfire 10.03.1-rc5 in hope that Wireless N mode will work better on my WRT350N seeing so many fixes. But unfortunately router starts to lag a lot when g+n mode is activated. Most noticeable when browsing web. Router is not heavily loaded at that time (mostly idle).
Here's a part of Ping procedure. Those 4 timeouts are during the time OpenWRT is applying changes (changing from g+n mode to g only). As you can see, in there is a very big difference in ping times in both modes.
Oh, and my wireless client is Intel WiFi Link 5300 AGN

Reply from 192.168.1.1: bytes=32 time=825ms TTL=64
Reply from 192.168.1.1: bytes=32 time=875ms TTL=64
Reply from 192.168.1.1: bytes=32 time=785ms TTL=64
Reply from 192.168.1.1: bytes=32 time=15ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=184ms TTL=64
Reply from 192.168.1.1: bytes=32 time=882ms TTL=64
Reply from 192.168.1.1: bytes=32 time=852ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1072ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1299ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1148ms TTL=64
Reply from 192.168.1.1: bytes=32 time=929ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=17ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=14ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=10ms TTL=64
Reply from 192.168.1.1: bytes=32 time=9ms TTL=64

Attachments (0)

Change History (77)

comment:1 Changed 7 years ago by Slowmo <slowmo@…>

Well, it appears that the problem affects G mode as well. So it is not related to N mode, but to wireless drivers in general. After around 24 hours, ping reply starts getting over 2000ms. If I disable and enable wireless, ping time gets normal again. There were no such problems with G mode in rc4.

comment:2 Changed 7 years ago by nbd

When that happens, please run iw wlan0 survey dump, then wait 30 seconds, then run it again. Paste the 'in use' part of the output of both runs here

comment:3 Changed 7 years ago by Slowmo <slowmo@…>

Ok, so now I am getting around half a second average ping reply time.

Here's an output of both runs

Survey data from wlan0
        frequency:                      2462 MHz [in use]
        noise:                          -95 dBm
        channel active time:            229439141 ms
        channel busy time:              227086647 ms
        channel receive time:           3342462 ms
        channel transmit time:          2906823 ms

Survey data from wlan0
        frequency:                      2462 MHz [in use]
        noise:                          -95 dBm
        channel active time:            229469164 ms
        channel busy time:              227116431 ms
        channel receive time:           3342923 ms
        channel transmit time:          2907308 ms

comment:4 Changed 7 years ago by Slowmo <slowmo@…>

After my previous post I started getting normal ping response (less than 15ms on average) and then I realized what is actually happening.
There is another laptop which was switched on and as soon as it was switched off, response became good again. So I switched it back again and sure enough, as soon as there is a network activity on that laptop (browsing web or streaming something), I get long ping reply times and lost packets on my computer. If it is not using the Internet, but remains switched on, everything is fine as well.
Wireless client on that other computer is Intel 4965AGN.

comment:5 Changed 7 years ago by nbd

The busy time is unusually high, have you tried using a different channel?

comment:6 Changed 6 years ago by Slowmo <slowmo@…>

Just tried to switch to another channel and no improvement.
I live in a private house where there are no other wireless networks around. Closest should be more than 1km away.
There was a problem when I switched channels. Wireless reconnected for a short while and then connection was dropped. After that I could not reconnect to it. Access point was visible but no connection could be made to it.
Here's what's inside system log:

Aug  6 20:52:26 OpenWrt daemon.warn dnsmasq[2547]: failed to access /tmp/resolv.conf.auto: No such file or directory
Aug  6 20:52:27 OpenWrt user.info firewall: removing wan (wan) from zone wan
Aug  6 20:52:29 OpenWrt user.info firewall: removing lan (br-lan) from zone lan
Aug  6 20:52:29 OpenWrt user.info kernel: wan: link down
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 5(wlan0) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 3(lan3) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 1(lan1) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: device eth0 left promiscuous mode
Aug  6 20:52:30 OpenWrt user.info kernel: device wlan0 left promiscuous mode
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 5(wlan0) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: device lan4 left promiscuous mode
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 4(lan4) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: device lan3 left promiscuous mode
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 3(lan3) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: device lan2 left promiscuous mode
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 2(lan2) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: device lan1 left promiscuous mode
Aug  6 20:52:30 OpenWrt user.info kernel: br-lan: port 1(lan1) entering disabled state
Aug  6 20:52:30 OpenWrt user.info kernel: lan1: link down
Aug  6 20:52:30 OpenWrt user.info kernel: lan3: link down
Aug  6 20:52:32 OpenWrt user.notice ifup: Enabling Router Solicitations on loopback (lo)
Aug  6 20:52:32 OpenWrt user.info kernel: eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Aug  6 20:52:32 OpenWrt user.notice rdate: No usable time server for loopback found
Aug  6 20:52:32 OpenWrt user.info kernel: wan: link up, 100 Mb/s, full duplex, flow control disabled
Aug  6 20:52:33 OpenWrt user.info kernel: lan1: link up, 1000 Mb/s, full duplex, flow control disabled
Aug  6 20:52:34 OpenWrt user.info kernel: device lan1 entered promiscuous mode
Aug  6 20:52:34 OpenWrt user.info kernel: device eth0 entered promiscuous mode
Aug  6 20:52:34 OpenWrt user.info kernel: br-lan: port 1(lan1) entering forwarding state
Aug  6 20:52:35 OpenWrt user.info kernel: device lan2 entered promiscuous mode
Aug  6 20:52:35 OpenWrt user.info kernel: device lan3 entered promiscuous mode
Aug  6 20:52:35 OpenWrt user.info kernel: device lan4 entered promiscuous mode
Aug  6 20:52:35 OpenWrt user.notice ifup: Allowing Router Advertisements on wan (wan)
Aug  6 20:52:35 OpenWrt user.info kernel: lan3: link up, 100 Mb/s, full duplex, flow control disabled
Aug  6 20:52:35 OpenWrt user.info kernel: br-lan: port 3(lan3) entering forwarding state
Aug  6 20:52:36 OpenWrt user.info kernel: br-lan: port 3(lan3) entering disabled state
Aug  6 20:52:36 OpenWrt user.info kernel: br-lan: port 1(lan1) entering disabled state
Aug  6 20:52:36 OpenWrt user.info kernel: br-lan: port 3(lan3) entering forwarding state
Aug  6 20:52:36 OpenWrt user.info kernel: br-lan: port 1(lan1) entering forwarding state
Aug  6 20:52:36 OpenWrt daemon.info dnsmasq[2547]: reading /tmp/resolv.conf.auto
Aug  6 20:52:36 OpenWrt daemon.info dnsmasq[2547]: using nameserver 195.122.12.242#53
Aug  6 20:52:36 OpenWrt daemon.info dnsmasq[2547]: using nameserver 80.232.230.242#53
Aug  6 20:52:36 OpenWrt daemon.info dnsmasq[2547]: using local addresses only for domain lan
Aug  6 20:52:37 OpenWrt user.notice ifup: Enabling Router Solicitations on lan (br-lan)
Aug  6 20:52:40 OpenWrt user.info firewall: adding wan (wan) to zone wan
Aug  6 20:52:40 OpenWrt user.notice rdate: Synced with ptbtime2.ptb.de
Aug  6 20:52:41 OpenWrt user.info kernel: device wlan0 entered promiscuous mode
Aug  6 20:52:41 OpenWrt user.info kernel: br-lan: port 5(wlan0) entering forwarding state
Aug  6 20:52:41 OpenWrt user.notice rdate: No usable time server for lan found
Aug  6 20:52:41 OpenWrt user.info firewall: adding lan (br-lan) to zone lan
Aug  6 20:52:44 OpenWrt user.info kernel: device wlan0 left promiscuous mode
Aug  6 20:52:44 OpenWrt user.info kernel: br-lan: port 5(wlan0) entering disabled state
Aug  6 20:52:44 OpenWrt user.info kernel: device wlan0 entered promiscuous mode
Aug  6 20:52:44 OpenWrt user.info kernel: br-lan: port 5(wlan0) entering forwarding state
Aug  6 20:54:10 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:15 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:20 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:20 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:25 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: associated (aid 1)
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac WPA: pairwise key handshake completed (RSN)
Aug  6 20:54:30 OpenWrt daemon.info dnsmasq-dhcp[2547]: DHCPREQUEST(br-lan) 192.168.1.104 00:16:ea:ec:dd:ac 
Aug  6 20:54:30 OpenWrt daemon.info dnsmasq-dhcp[2547]: DHCPACK(br-lan) 192.168.1.104 00:16:ea:ec:dd:ac lauris
Aug  6 20:54:30 OpenWrt daemon.warn dnsmasq-dhcp[2547]: Ignoring domain mtoy.local for DHCP host name lauris
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 2)
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug  6 20:54:30 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: pairwise key handshake completed (RSN)
Aug  6 20:54:48 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:50 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:53 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:54:59 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:55:01 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:55:01 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:55:03 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:55:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug  6 20:55:08 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug  6 20:55:11 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response

comment:7 Changed 6 years ago by nbd

Please make a build of current backfire SVN, and enable CONFIG_PACKAGE_ATH_DEBUG ("Atheros wireless debugging") in the config. After booting it, unload the ath9k module and load it with the debug=8 module parameter and post the kernel messages when the issues start happening.

comment:8 Changed 6 years ago by Slowmo <slowmo@…>

It seems after upgrading to trunk, my problems with wireless are gone, but as I can see, I am not the only one complaining about wireless stability in rc5 build.

Although I managed to set up a build environment and actually compile the trunk, I am not entirely sure how to enable CONFIG_PACKAGE_ATH_DEBUG and what are the proper commands for stopping ath9k and running it with debug=8. I can see CONFIG_PACKAGE_ATH_DEBUG in "make menuconfig". Is this what I need to check? Also, what is a performance penalty when leaving driver in debug mode? Can I leave it on just in case I experience a new problem?

comment:9 Changed 6 years ago by nbd

please also try latest trunk to make sure it's also fixed there

comment:10 Changed 6 years ago by Slowmo <slowmo@…>

So some changes were made to trunk recently which I should check or did you mean the latest Backfire?

comment:11 Changed 6 years ago by nbd

yes, there were some changes in trunk recently. if the version of mac80211 in there ends up working well for enough people, i will commit it to backfire as well.

comment:12 Changed 6 years ago by nbd

  • Owner changed from developers to nbd
  • Status changed from new to accepted

comment:13 Changed 6 years ago by Slowmo <slowmo@…>

Ok, so now I am on r28133 and here is a system log

Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:55 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:27:55 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:27:56 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:56 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug 31 09:27:56 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:56 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:57 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Aug 31 09:27:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:59 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Aug 31 09:27:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:27:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:27:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug 31 09:28:02 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:05 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:05 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:06 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:10 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:10 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:11 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:11 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:11 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:11 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:15 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:15 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:15 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 0)
Aug 31 09:28:15 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: Could not add STA to kernel driver
Aug 31 09:28:16 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:16 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug 31 09:28:16 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug 31 09:28:21 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:23 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Aug 31 09:28:28 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug 31 09:28:28 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug 31 09:28:30 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug 31 09:28:30 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: pairwise key handshake completed (RSN)
Aug 31 09:29:01 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Aug 31 09:29:01 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: associated (aid 2)
Aug 31 09:29:01 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac WPA: pairwise key handshake completed (RSN)

Also system load is high now
Load: 1.05 0.95 0.55

comment:14 Changed 6 years ago by Slowmo <slowmo@…>

Besides high load, wireless is almost unusable now. Tried 'wifi' command, to restart wireless driver, but router crashed completely. Had to power cycle the device.
Oh, and before crash I got the following console output:

root@OpenWrt:~# wifi
command failed: No such device (-19)

comment:15 Changed 6 years ago by nbd

please try the latest version, this issue should be fixed now

comment:16 Changed 6 years ago by Slowmo <slowmo@…>

Just after reflashing when router booted up, I got no wireless. Tried 'wifi' command and it gave me the following message:

Configuration file: /var/run/hostapd-phy0.conf
Using interface wlan0 with hwaddr 00:14:a5:c0:e7:ec and ssid 'openwrt'
random: Cannot read from /dev/random: Resource temporarily unavailable
random: Only 0/20 bytes of strong random data available from /dev/random
random: Not enough entropy pool available for secure operations
WPA: Not enough entropy in random pool for secure operations - update keys later when the first station connects

After soft reboot wireless started working but totally unusable. Hard reboot of the device resulted in a little bit better situation but still there are a lot of dropped packets.

Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=42ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=11ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=11ms TTL=64
Reply from 192.168.1.1: bytes=32 time=11ms TTL=64
Reply from 192.168.1.1: bytes=32 time=10ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64

Also what is strange now that one of wireless clients is shown twice in "Associated Stations" list. Both records have different signal and noise values. DHCP section also has two records for different client (currently off) with identical hostmame, IP and MAC address but different expiring times.

comment:17 Changed 6 years ago by nbd

please try r28245

comment:18 Changed 6 years ago by Slowmo <slowmo@…>

Looks like after update to r28245 connection got even worse. I left my laptop on at night with a strong signal and ping running. Got around 5% lost packets. And now the other laptop running in G mode has the same problems, which it did not have before the update. Actually the person using that laptop complained to me that everything is very slow today.
So is there a way to diagnose why the packets are lost? As I mentioned before, I live in a house where there are no other wireless networks around and I can't think of a source of interference which could cause network issues.

comment:19 Changed 6 years ago by Slowmo <slowmo@…>

Ok, so it seems I am back to the same issue I had a couple of weeks ago when I reported that wireless was completely unusable. Tried copying a file from a computer which is connected to the router by gigabit connection and I get like 2Kb/s transfer speed and file copy window freezes. After performing wifi command I again get an error.

root@openwrt:~# wifi
command failed: No such device (-19)
Configuration file: /var/run/hostapd-phy0.conf
Using interface wlan0 with hwaddr 00:14:a5:c0:e7:ec and ssid 'openwrt'

Oh, and in system log there are deauthentication messages again.

Sep 16 20:46:52 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Sep 16 20:46:52 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Sep 16 20:46:52 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Sep 16 20:46:52 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Sep 16 20:46:53 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Sep 16 20:46:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Sep 16 20:46:54 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Sep 16 20:46:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Sep 16 20:46:58 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Sep 16 20:46:58 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)

comment:20 Changed 6 years ago by Slowmo <slowmo@…>

Reverted back to r28253 where G mode is more or less stable. So wireless-testing 2011-09-14 makes G mode unusable as well.

comment:21 Changed 6 years ago by nbd

please try r28301

comment:22 Changed 6 years ago by Slowmo <slowmo@…>

The further, the worse. Now I have lost wireless completely. Radio sits at around -94dBm noise level with 0dBm signal. Wireless clients don't see any wireless networks.
A couple of days ago I noticed an interesting thing. The second I unplugged my cordless phone base, I lost my wireless. At first I thought it was coincidence, but then I was able to repeat the behavior. So I thought I found a reason for my wireless problems, but now it does not matter if the phone is switched off or on, wireless is not working at all. My next thought was that router got damaged somehow so I loaded back the stock firmware but to my surprise, everything works fine there.

Now I'm back to OpenWRT with no wireless. Tried everything - different channels, encryptions, even reset all settings to default with no luck.
Now I also get this output with wifi command:

root@OpenWrt:~# wifi
Configuration file: /var/run/hostapd-phy0.conf
Using interface wlan0 with hwaddr 00:14:a5:c0:e7:ec and ssid 'OpenWRT'
random: Cannot read from /dev/random: Resource temporarily unavailable
random: Only 0/20 bytes of strong random data available from /dev/random
random: Not enough entropy pool available for secure operations
WPA: Not enough entropy in random pool for secure operations - update keys later when the first station connects

Created a symlink to urandom and these messages are not displayed anymore, but that does not bring wireless back.
System log is full of such messages:

Sep 27 20:36:19 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:19 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:21 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Sep 27 20:36:21 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:23 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Sep 27 20:36:23 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:23 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:24 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Sep 27 20:36:24 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:24 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Sep 27 20:36:24 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:24 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:26 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Sep 27 20:36:26 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:26 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Sep 27 20:36:26 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:36:26 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:37:15 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Sep 27 20:37:15 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:37:17 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Sep 27 20:37:17 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:37:17 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:37:20 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Sep 27 20:37:20 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:37:20 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Sep 27 20:37:20 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Sep 27 20:37:20 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state

comment:23 Changed 6 years ago by nbd

Please try latest

comment:24 Changed 6 years ago by Slowmo <slowmo@…>

I'm currently on r28423 but no luck. Still no wireless and "wifi" command gives the same "Cannot read from /dev/random" message.
I even tried deleting everything and building the image from scratch, but that did not change anything. Stock firmware however works fine.

comment:25 Changed 6 years ago by Slowmo <slowmo@…>

Just went back to 10.03.1-rc5 and wireless is working there (but with currently fixed problems). So either my builds are bad or there are problems in trunk.

comment:26 Changed 6 years ago by nbd

the /dev/random message is normal, it'll only cause the first connection attempt to fail, all subsequent attempts should work.

comment:27 Changed 6 years ago by Slowmo <slowmo@…>

Just checked the latest snapshot build which is r28442 and verified that my own builds were ok. Wireless is not working.
If I disable wireless security, my ssid becomes visible to clients, but it is not possible to connect to it. As soon as I enable security, ssid is not even visible and router reports 0dBm signal and noise somewhere between -95 and -90 dBm (changing).

comment:28 Changed 6 years ago by nbd

please try r28772

comment:29 Changed 6 years ago by Slowmo <slowmo@…>

Nope, no luck.
However things I notice now is that my ssid is visible all the time. It is not disappearing and appearing all the time and log file is not spammed with promiscuous mode and forwarding state messages. And wifi command does not give error about /dev/random anymore, but unfortunately clients can not connect. There is no response from the router while connecting.
Is there anything I could do to help understand what is happening here? What about CONFIG_PACKAGE_ATH_DEBUG? Can you explain in detail what should I do to get the debug information?

comment:30 Changed 6 years ago by nbd

Please try copying http://nbd.name/910-ani_test.patch to package/mac80211/patches, rebuild and try again.

comment:31 Changed 6 years ago by Slowmo <slowmo@…>

After this patch my ssid is not visible to clients anymore. Even when security is disabled.
After 'wifi' command there is a following output in system log:

Nov  8 12:04:17 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Nov  8 12:04:17 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Nov  8 12:04:17 OpenWrt kern.err kernel: ath: Failed to stop TX DMA, queues=0x001!
Nov  8 12:04:18 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Nov  8 12:04:18 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Nov  8 12:04:18 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Nov  8 12:04:21 OpenWrt kern.info kernel: device wlan0 left promiscuous mode
Nov  8 12:04:21 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Nov  8 12:04:21 OpenWrt kern.info kernel: device wlan0 entered promiscuous mode
Nov  8 12:04:21 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state
Nov  8 12:04:21 OpenWrt kern.info kernel: br-lan: port 5(wlan0) entering forwarding state

comment:32 Changed 6 years ago by nbd

please try the latest version

comment:33 Changed 6 years ago by Slowmo <slowmo@…>

No, still the same. And just in case also verified that in rc6 my wireless does not work as well. Now I'm back to rc4 where at least G mode is more or less stable.

comment:34 Changed 6 years ago by mm@…

I see exactly the same problems. No wifi with trunk (r29288)
The driver seems to load fine, the essid is visible, but no association is possible:

wlan0: authenticate with 12:34:56:00:02:8a (try 1)
wlan0: authenticate with 12:34:56:00:02:8a (try 2)
wlan0: authenticate with 12:34:56:00:02:8a (try 3)
wlan0: authentication with 12:34:56:00:02:8a timed out

comment:35 Changed 6 years ago by nbd

please try latest trunk

comment:36 Changed 6 years ago by Slowmo <slowmo@…>

No, still can't connect. And now there is additional problem. I can not set a root password in Luci. Although it says that password has been successfully changed, it is not. Red warning box is always visible at the top telling to set a password. I can not make an SSH connection as well. Empty password is not accepted. Luci however can log in with any password, but no matter how many times I try to set the password, it does not work.

comment:37 Changed 6 years ago by jow

For password issue see #10537, #10405, #10412, #10393

comment:38 Changed 6 years ago by maddes

  • Cc maddes added

comment:39 Changed 6 years ago by Slowmo <slowmo@…>

Ok, so now I am 100% sure am affected by my cordless phone but in a very odd way. I hope you will have some ideas.

I have already mentioned this in this ticket but now I did repeated tests and what I see is if I unplug the base of a cordless phone, wireless goes off immediately (SSID disappears). It appears again a couple of seconds after the base is plugged in. Initially I thought the phone itself is starting to look for a base and jams the network, but it is not true. The same happens if I switch it off.
I also thought that maybe router somehow calibrates itself so I rebooted the router while phone base was switched off. Still no wireless. I plug the base back in and sure enough - SSID appears again. Needless to say - my access point which I am now using for wireless (g mode) is not affected in any way. I get a stable signal all the time.

Oh, and today I was able to connect to my router wirelessly for a while and I observed some strange reports of signal strength (at least to me they looked strange). While connected, the signal strength bar only showed around 8% signal and about 4dBm. If signal strength increases, dBm value decreases. Occasionally it jumps to 100% for a short while and then dB value is only about -30dBm. In some cases it even dropped to around -70dBm during 100% interval. Is it normal? Transmit power is set to 20dBm and noise level is more or less stable at -93dBm. During these tests my distance from the router was about 2.5m in a direct line of sight. My laptop reported full bars of signal all the time.

Issue of cordless phone disappears if I downgrade to 10.03.1-rc4 or older.

Any ideas?

P.S
My cordless phone is a Panasonic KX-A143EXW. Not much can be found about it as it is a discontinued model, but it is DECT. I can't even find which frequency band it operate in, but I assume it is 2.4GHz

comment:40 Changed 6 years ago by nbd

Please try a recent version of trunk to check if the issue is still there.

comment:41 Changed 6 years ago by superspost@…

Just to confirm - i have installed the latest snapshot ATTITUDE ADJUSTMENT (bleeding edge, r30688) from 23.02.2012 and wireless does not come up at all.... i have tried g only and g+n settings with and without encryption - but signal strength remains at 0dBm all the time... I have my laptop right next to the station and can see the network from there - but cant connect to it.

I had tried the latest version because i had really slow wifi speeds with 10.03.1 and while searching for a solution found this ticket...

I have also tried to unplug my cordless phone - as Slowmo mentioned issues, but do not see any difference...

router is wrt350n v2.1

comment:42 Changed 6 years ago by Slowmo <slowmo@…>

I haven't been able to test the latest trunk. My RAID failed where I keep the virtual image of configured build system for OpenWRT. Currently doing a very lengthy recovery.

But I am glad I'm not the only one with this issue, because the description in previous post is exactly what I am seeing on my router.

comment:43 Changed 6 years ago by superspost@…

Today i have downloaded the latest trunk version (openwrt-wrt350nv2-squashfs.img) from 29-Feb-2012 11:24 again to check whether there are any changes...

in normal station mode wifi still cant be accessed..

Anybody else with an wrt350nv2 having the same problems?

comment:44 Changed 6 years ago by mm@…

I still have the issue too.

comment:45 Changed 6 years ago by mm@…

Actually I have to correct me, though it behaves a bit strange. The ESSID didn't show up on air after flashing the current trunk snapshot from downloads, but I forgot to switch it off and 5min ago I realised it's ESSID showed up on my mobile. Looking at it further it shows, that after bringing the interface up, the wrt350n sends a couple of beacons (around 20) then falls silent. After that it sends out spurious Probe Responses, but no beacons anymore.

comment:46 Changed 6 years ago by superspost@…

out of curiosity i have updated my wrt350nv2 now to ATTITUDE ADJUSTMENT (bleeding edge, r31179)
have installed luci and got the wifi up which is accessible now. ran a ping to the main router (see below)

what seems striking to me is that every 20ms or so there is this massive delay - very periodically. like some hartbeat signal.

any idea what could be causing this delay? is the patch from nbd (mentioned some posts above) already included in the latest trunk version? which problem does the patch address?

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.337 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=1.262 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=9.081 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=1.270 ms
64 bytes from 192.168.1.1: seq=4 ttl=64 time=1.719 ms
64 bytes from 192.168.1.1: seq=5 ttl=64 time=1.957 ms
64 bytes from 192.168.1.1: seq=6 ttl=64 time=1.614 ms
64 bytes from 192.168.1.1: seq=7 ttl=64 time=18.526 ms
64 bytes from 192.168.1.1: seq=8 ttl=64 time=1474.828 ms
64 bytes from 192.168.1.1: seq=9 ttl=64 time=478.055 ms
64 bytes from 192.168.1.1: seq=10 ttl=64 time=1.328 ms
64 bytes from 192.168.1.1: seq=11 ttl=64 time=1.263 ms
64 bytes from 192.168.1.1: seq=12 ttl=64 time=2.013 ms
64 bytes from 192.168.1.1: seq=13 ttl=64 time=1.269 ms
64 bytes from 192.168.1.1: seq=14 ttl=64 time=1.412 ms
64 bytes from 192.168.1.1: seq=15 ttl=64 time=1.638 ms
64 bytes from 192.168.1.1: seq=16 ttl=64 time=1.802 ms
64 bytes from 192.168.1.1: seq=17 ttl=64 time=1.264 ms
64 bytes from 192.168.1.1: seq=18 ttl=64 time=1.392 ms
64 bytes from 192.168.1.1: seq=19 ttl=64 time=2.309 ms
64 bytes from 192.168.1.1: seq=20 ttl=64 time=1.293 ms
64 bytes from 192.168.1.1: seq=21 ttl=64 time=1.287 ms
64 bytes from 192.168.1.1: seq=22 ttl=64 time=1.302 ms
64 bytes from 192.168.1.1: seq=23 ttl=64 time=1.298 ms
64 bytes from 192.168.1.1: seq=24 ttl=64 time=1.296 ms
64 bytes from 192.168.1.1: seq=25 ttl=64 time=1.803 ms
64 bytes from 192.168.1.1: seq=26 ttl=64 time=1.213 ms
64 bytes from 192.168.1.1: seq=27 ttl=64 time=1.277 ms
64 bytes from 192.168.1.1: seq=28 ttl=64 time=1.261 ms
64 bytes from 192.168.1.1: seq=29 ttl=64 time=1.282 ms
64 bytes from 192.168.1.1: seq=30 ttl=64 time=1.345 ms
64 bytes from 192.168.1.1: seq=31 ttl=64 time=1.331 ms
64 bytes from 192.168.1.1: seq=32 ttl=64 time=1.382 ms
64 bytes from 192.168.1.1: seq=33 ttl=64 time=1.482 ms
64 bytes from 192.168.1.1: seq=34 ttl=64 time=1.351 ms
64 bytes from 192.168.1.1: seq=35 ttl=64 time=1.272 ms
64 bytes from 192.168.1.1: seq=36 ttl=64 time=1.270 ms
64 bytes from 192.168.1.1: seq=37 ttl=64 time=1.237 ms
64 bytes from 192.168.1.1: seq=38 ttl=64 time=1.299 ms
64 bytes from 192.168.1.1: seq=39 ttl=64 time=4.511 ms
64 bytes from 192.168.1.1: seq=40 ttl=64 time=1463.680 ms
64 bytes from 192.168.1.1: seq=42 ttl=64 time=2.154 ms
64 bytes from 192.168.1.1: seq=43 ttl=64 time=1.330 ms
64 bytes from 192.168.1.1: seq=44 ttl=64 time=4.935 ms
64 bytes from 192.168.1.1: seq=45 ttl=64 time=1.309 ms
64 bytes from 192.168.1.1: seq=46 ttl=64 time=1.287 ms
64 bytes from 192.168.1.1: seq=47 ttl=64 time=1.300 ms
64 bytes from 192.168.1.1: seq=48 ttl=64 time=1.299 ms
64 bytes from 192.168.1.1: seq=49 ttl=64 time=1.308 ms
64 bytes from 192.168.1.1: seq=50 ttl=64 time=1.305 ms
64 bytes from 192.168.1.1: seq=51 ttl=64 time=1.279 ms
64 bytes from 192.168.1.1: seq=52 ttl=64 time=4.435 ms
64 bytes from 192.168.1.1: seq=53 ttl=64 time=1.298 ms
64 bytes from 192.168.1.1: seq=54 ttl=64 time=1.293 ms
64 bytes from 192.168.1.1: seq=55 ttl=64 time=1.259 ms
64 bytes from 192.168.1.1: seq=56 ttl=64 time=1.322 ms
64 bytes from 192.168.1.1: seq=57 ttl=64 time=1.720 ms
64 bytes from 192.168.1.1: seq=58 ttl=64 time=1.293 ms
64 bytes from 192.168.1.1: seq=59 ttl=64 time=2.663 ms
64 bytes from 192.168.1.1: seq=60 ttl=64 time=1.281 ms
64 bytes from 192.168.1.1: seq=61 ttl=64 time=1.284 ms
64 bytes from 192.168.1.1: seq=62 ttl=64 time=2.057 ms
64 bytes from 192.168.1.1: seq=63 ttl=64 time=1.369 ms
64 bytes from 192.168.1.1: seq=64 ttl=64 time=1.270 ms
64 bytes from 192.168.1.1: seq=65 ttl=64 time=3.952 ms
64 bytes from 192.168.1.1: seq=66 ttl=64 time=1.396 ms
64 bytes from 192.168.1.1: seq=67 ttl=64 time=1.296 ms
64 bytes from 192.168.1.1: seq=68 ttl=64 time=1.316 ms
64 bytes from 192.168.1.1: seq=69 ttl=64 time=1.319 ms
64 bytes from 192.168.1.1: seq=70 ttl=64 time=1.330 ms
64 bytes from 192.168.1.1: seq=71 ttl=64 time=1.266 ms
64 bytes from 192.168.1.1: seq=72 ttl=64 time=1449.977 ms
64 bytes from 192.168.1.1: seq=73 ttl=64 time=454.242 ms
64 bytes from 192.168.1.1: seq=74 ttl=64 time=1.328 ms
64 bytes from 192.168.1.1: seq=75 ttl=64 time=1.306 ms
64 bytes from 192.168.1.1: seq=76 ttl=64 time=1.344 ms
64 bytes from 192.168.1.1: seq=77 ttl=64 time=1.268 ms
64 bytes from 192.168.1.1: seq=78 ttl=64 time=4.253 ms
64 bytes from 192.168.1.1: seq=79 ttl=64 time=1.265 ms
64 bytes from 192.168.1.1: seq=80 ttl=64 time=1.282 ms
64 bytes from 192.168.1.1: seq=81 ttl=64 time=1.275 ms
64 bytes from 192.168.1.1: seq=82 ttl=64 time=1.254 ms
64 bytes from 192.168.1.1: seq=83 ttl=64 time=1.330 ms
64 bytes from 192.168.1.1: seq=84 ttl=64 time=1.290 ms
64 bytes from 192.168.1.1: seq=85 ttl=64 time=1.291 ms
64 bytes from 192.168.1.1: seq=86 ttl=64 time=1.314 ms
64 bytes from 192.168.1.1: seq=87 ttl=64 time=2.010 ms
64 bytes from 192.168.1.1: seq=88 ttl=64 time=4.544 ms
64 bytes from 192.168.1.1: seq=89 ttl=64 time=1.277 ms
64 bytes from 192.168.1.1: seq=90 ttl=64 time=1.294 ms
64 bytes from 192.168.1.1: seq=91 ttl=64 time=4.109 ms
64 bytes from 192.168.1.1: seq=92 ttl=64 time=1.635 ms
64 bytes from 192.168.1.1: seq=93 ttl=64 time=1.526 ms
64 bytes from 192.168.1.1: seq=94 ttl=64 time=1.314 ms
64 bytes from 192.168.1.1: seq=95 ttl=64 time=1.296 ms
64 bytes from 192.168.1.1: seq=96 ttl=64 time=1.311 ms
64 bytes from 192.168.1.1: seq=97 ttl=64 time=1.304 ms
64 bytes from 192.168.1.1: seq=98 ttl=64 time=1.653 ms
^C
--- 192.168.1.1 ping statistics ---
99 packets transmitted, 98 packets received, 1% packet loss
round-trip min/avg/max = 1.213/56.102/1474.828 ms
root@router-2:~# 

comment:47 Changed 6 years ago by nbd

please try the latest version

comment:48 Changed 6 years ago by mm@…

current trunk snapshots panic with unable to mount root when flashing either via uboot or upslug2 http://downloads.openwrt.org/snapshots/trunk/orion/openwrt-wrt350nv2-squashfs-recovery.bin

comment:49 Changed 6 years ago by maddes

@mm:
My builds of r32463 boot well, but was flashed with sysupgarde (pure trunk, no modifications)
ftp://ftp.maddes.net/openwrt/trunk/orion/build_32463/
Just to let you know

comment:50 Changed 6 years ago by mm@…

@maddes: Thanks, your image boots and seems to work.

comment:51 Changed 6 years ago by Slowmo <slowmo@…>

Which file can I use to do an update from Luci web interface? I would like to test as well, but don't have time to create a new build system as my existing one crashed a while ago.

comment:52 Changed 6 years ago by maddes

@Slowmo:
Normally the squashfs sysupgrade image. "openwrt-wrt350nv2-squashfs.release+ipv6-luci.img" on my ftp.

comment:53 Changed 6 years ago by Slowmo <slowmo@…>

Ok, so I'm running r32463 now and unfortunately nothing has changed for me. SSID is not visible and wireless signal sits at 0 dBm

comment:54 Changed 6 years ago by mm@…

Hi, I can somehow see your problem. I checked out r32484 and built my own images and packages. when flashing a new image I have sometimes (about 2 out of 5 times) the Problem you see. It seems to some initialisation issue, as powering off the router for more than a minute fixes the problem for me most of the time. If this error occurs issuing the command "wifi down" crashes the router. If the wlan is correctly initialised "wifi down" and "wifi up" work well.

comment:55 Changed 6 years ago by nbd

please try r32510

comment:56 Changed 6 years ago by mm@…

The issue with WLAN not working after flashing and requiring a 1min power cycle on the router is still there. Except from that wifi works for me in HT20 mode, but not in HT40(+-) mode with the noscan option. Throughput is about 6.5MB/s.

comment:57 Changed 5 years ago by Slowmo <slowmo@…>

Just flashed r33311 and was able to get wifi working in HT20 mode as well. Then I had a go at HT40 and router started rebooting itself immediately after wireless connection is made. Now I went back to HT20 and it still reboots after the client connects to it. Even 1min power cycle does not help.

comment:58 Changed 5 years ago by maddes

Just a small note:
Try firstboot to reset to initial state after flash, this allows you to do further tests without reflashing.

comment:59 Changed 5 years ago by gladia2r@…

Hey, this issue happened to me as well, it was related to my laptop Wifi power settings, you should set to Performance all options and you should be good to go!

comment:60 Changed 5 years ago by Slowmo <slowmo@…>

After running /sbin/firstboot script, I configured WiFi to run in HT20 mode and now even that does not work. As soon as connection is made, router restarts. Not sure why it worked without problems immediately after flashing the firmware. Not that I gave a proper test, but at least it worked fine for a couple of hours until I decided to try a HT40 mode.

comment:61 Changed 5 years ago by nbd

anything in /sys/kernel/debug/crashlog?

comment:62 Changed 5 years ago by Slowmo <slowmo@…>

No, unfortunately there is no crashlog.

comment:63 Changed 5 years ago by Slowmo <slowmo@…>

Just noticed one more strange thing.
If wireless is enabled and I plug a gigabit connection on one of router's ports, it restarts immediately. 3 other switch ports are currently 100Mbit connections and those work fine. If however wireless is disabled, gigabit connection works fine and there are no restarts.
I found this strange behavior by accident, because I had a computer with gigabit card connected to the router. This computer is not normally switched on or if it is, wireless was always off. I could not understand why I can't even start up the router as it restarts at the point where boot should be complete and never reaches fully booted state. I had switched wireless clients off and still no luck. So I started unplugging the Ethernet cables and found that it switched on if gigabit connection is not there. I also verified that it is not one particular port. Gigabit connection is causing problem on any of 4 ports.
So if we take that hardware is not faulty, how we can explain this behavior?

comment:64 Changed 5 years ago by nbd

please try the latest version of trunk or attitude_adjustment, the fix in r33989/r33990 could be relevant.

comment:65 Changed 5 years ago by Slowmo <slowmo@…>

I'll have to wait for beta3 to test as I have currently nowhere to build a trunk. I can't use snapshot builds as there is something wrong with them. Probably bad configuration.

comment:66 Changed 5 years ago by Slowmo <slowmo@…>

Ok, so I'm on 12.09-rc1 now, and problems are still there. Router keeps restarting when wireless enabled, but now I see it is not related to gigabit connection. Somehow it chooses one device which it does not like and restarts immediately when it is plugged in in any port. Last time it happened to be a computer with gigablit LAN, but now it is my wireless AP, which I am forced to use as I can't use wifi on my router.

Here's what system log looks like when I try to connect to my router wirelessly.

Dec  1 11:06:40 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:06:40 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: associated (aid 1)
Dec  1 11:06:55 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:06:55 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: associated (aid 1)
Dec  1 11:06:58 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:06:58 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:06:59 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:00 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:07:00 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:01 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:07:01 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:04 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: disassociated due to inactivity
Dec  1 11:07:05 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Dec  1 11:07:07 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:07:07 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:08 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:07:08 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:09 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:07:10 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:10 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response
Dec  1 11:07:11 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:11 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: associated (aid 1)
Dec  1 11:07:18 OpenWrt daemon.info hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: authenticated
Dec  1 11:07:18 OpenWrt daemon.notice hostapd: wlan0: STA 00:16:ea:ec:dd:ac IEEE 802.11: did not acknowledge authentication response

comment:67 Changed 5 years ago by kerneis@…

I can confirm the "spiking" issue with 12.09-rc1.

On a client using the iwlwifi driver (with software crypto):

$ uname -a
Linux wacehi 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
$ ping ocanku
PING ocanku.lan (192.168.1.1) 56(84) bytes of data.
64 bytes from ocanku.lan (192.168.1.1): icmp_req=1 ttl=64 time=2.57 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=2 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=3 ttl=64 time=3.75 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=4 ttl=64 time=2.50 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=5 ttl=64 time=2.56 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=6 ttl=64 time=285 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=7 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=8 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=9 ttl=64 time=3.77 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=10 ttl=64 time=7.58 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=11 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=12 ttl=64 time=2.56 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=13 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=14 ttl=64 time=252 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=15 ttl=64 time=2.62 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=16 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=17 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=18 ttl=64 time=133 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=19 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=20 ttl=64 time=2.58 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=21 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=22 ttl=64 time=2.57 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=23 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=24 ttl=64 time=2.55 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=25 ttl=64 time=2.52 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=26 ttl=64 time=6.68 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=27 ttl=64 time=3.04 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=28 ttl=64 time=403 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=29 ttl=64 time=2.59 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=30 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=31 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=32 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=33 ttl=64 time=2.62 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=34 ttl=64 time=11.3 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=35 ttl=64 time=16.0 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=36 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=37 ttl=64 time=3.34 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=38 ttl=64 time=2.54 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=39 ttl=64 time=2.60 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=40 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=41 ttl=64 time=1.63 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=42 ttl=64 time=2.52 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=43 ttl=64 time=2.56 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=44 ttl=64 time=2.93 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=45 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=46 ttl=64 time=2.61 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=47 ttl=64 time=2.64 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=48 ttl=64 time=2.59 ms
64 bytes from ocanku.lan (192.168.1.1): icmp_req=49 ttl=64 time=27.1 ms
^C
--- ocanku.lan ping statistics ---
49 packets transmitted, 49 received, 0% packet loss, time 48067ms
rtt min/avg/max/mdev = 1.633/25.502/403.539/77.613 ms

The same happens with another client using ath9k driver. I've seen spikes as high as 1008ms but could not reproduce them reliably.

comment:68 Changed 5 years ago by nbd

please try r35786 or newer

comment:69 Changed 5 years ago by anonymous

Seems to work for now two days. Great.

comment:70 Changed 5 years ago by Slowmo <slowmo@…>

Can you send me the firmware you built for me to test?

comment:71 Changed 5 years ago by superspost@…

why are the orion packages not in the current snapshot folder anymore? could i also get your firmware? thanks

comment:72 Changed 5 years ago by Slowmo <slowmo@…>

I have tried snapshot builds for Orion before and they were bricking my router. I have opened a separate ticket #11852 for that, and it has been assigned to kaloz, but he has not looked into it.

comment:73 Changed 5 years ago by nbd

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

Seems to work now. Reopen with more information if it doesn't.

comment:74 Changed 5 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

I have exactly the same problem on my WDR4300, on both 2.4GHz and 5.0GHz, so i dont think its the channel problem. I use latest stable AA release.

comment:75 Changed 5 years ago by Slowmo <slowmo@…>

Can you clarify what problem are you having?
As for the problems with wireless, I don't think they are fixed. I'm on the latest release build and still experiencing router restarts when wireless is enabled (see my previous comment:63 and comment:66)

comment:76 Changed 5 years ago by nbd

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

This ticket was about an AR5416 issue, so anything on the WDR4300 is going to be a different issue. Please try latest git version (either a snapshot build or AA git). If that has the issue, make a new ticket with detailed information.

comment:77 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

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.

 
Note: See TracTickets for help on using tickets.