Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#14097 closed defect (fixed)

r37483 broke my WLAN on my Android

Reported by: anonymous Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: Cc:

Description

I'm running a TL-WA901ND v2.
Some days ago, I updated my OpenWrt installation to r37834 and I began to notice that my Android phone stopped working when it went to standby. After the phone gets waken up from standby, no further connection to the AP is possible. After quite some time and only in rare cases, the connection is back - maybe because my phone reconnected to the AP - I don't know.
But right after standby, my phone is indicating a link, and also that data is sent, but nothing comes back.

I can see this behaviour during pinging my phone....

  • massive high response times which are uncommon
  • at some point during standby 100% packet loss
  • When the phone is waken up, and I try to access the internet (which does not work), and the phone goes back to standby, I regain WLAN accessability after a long time automatically.

I tracked it down to the patches submitted with r37483.

https://dev.openwrt.org/changeset/37483/

With r37482, the phone works nice without any problems. It is pingable during the standby and when I wake it up I can immediatly access the network.
After updating OpenWrt to r37483 and I get the above described issues.

I can even notice this things when I have a ping running:

> ping 10.0.2.52
PING 10.0.2.52 (10.0.2.52): 56 data bytes
64 bytes from 10.0.2.52: icmp_seq=0 ttl=64 time=1130.534 ms
64 bytes from 10.0.2.52: icmp_seq=1 ttl=64 time=130.158 ms
64 bytes from 10.0.2.52: icmp_seq=2 ttl=64 time=158.788 ms
64 bytes from 10.0.2.52: icmp_seq=3 ttl=64 time=176.531 ms
64 bytes from 10.0.2.52: icmp_seq=5 ttl=64 time=2064.538 ms
64 bytes from 10.0.2.52: icmp_seq=6 ttl=64 time=1063.555 ms
64 bytes from 10.0.2.52: icmp_seq=7 ttl=64 time=62.583 ms
64 bytes from 10.0.2.52: icmp_seq=8 ttl=64 time=89.759 ms
64 bytes from 10.0.2.52: icmp_seq=9 ttl=64 time=107.847 ms
64 bytes from 10.0.2.52: icmp_seq=10 ttl=64 time=125.841 ms
64 bytes from 10.0.2.52: icmp_seq=11 ttl=64 time=153.567 ms
64 bytes from 10.0.2.52: icmp_seq=12 ttl=64 time=171.869 ms
64 bytes from 10.0.2.52: icmp_seq=13 ttl=64 time=200.574 ms
64 bytes from 10.0.2.52: icmp_seq=14 ttl=64 time=218.985 ms
64 bytes from 10.0.2.52: icmp_seq=15 ttl=64 time=37.940 ms
64 bytes from 10.0.2.52: icmp_seq=16 ttl=64 time=56.950 ms
64 bytes from 10.0.2.52: icmp_seq=17 ttl=64 time=85.666 ms
64 bytes from 10.0.2.52: icmp_seq=18 ttl=64 time=103.963 ms
64 bytes from 10.0.2.52: icmp_seq=19 ttl=64 time=132.941 ms
64 bytes from 10.0.2.52: icmp_seq=20 ttl=64 time=152.110 ms
64 bytes from 10.0.2.52: icmp_seq=21 ttl=64 time=171.558 ms
64 bytes from 10.0.2.52: icmp_seq=22 ttl=64 time=198.597 ms
64 bytes from 10.0.2.52: icmp_seq=23 ttl=64 time=217.002 ms
64 bytes from 10.0.2.52: icmp_seq=24 ttl=64 time=36.467 ms
64 bytes from 10.0.2.52: icmp_seq=25 ttl=64 time=54.630 ms
64 bytes from 10.0.2.52: icmp_seq=27 ttl=64 time=2152.367 ms
64 bytes from 10.0.2.52: icmp_seq=28 ttl=64 time=1152.985 ms
64 bytes from 10.0.2.52: icmp_seq=29 ttl=64 time=2202.313 ms
64 bytes from 10.0.2.52: icmp_seq=391 ttl=64 time=4.064 ms
64 bytes from 10.0.2.52: icmp_seq=392 ttl=64 time=1.543 ms
64 bytes from 10.0.2.52: icmp_seq=393 ttl=64 time=132.818 ms
64 bytes from 10.0.2.52: icmp_seq=394 ttl=64 time=1.663 ms
64 bytes from 10.0.2.52: icmp_seq=395 ttl=64 time=1.969 ms
64 bytes from 10.0.2.52: icmp_seq=396 ttl=64 time=1.640 ms
64 bytes from 10.0.2.52: icmp_seq=397 ttl=64 time=2.042 ms
64 bytes from 10.0.2.52: icmp_seq=398 ttl=64 time=456.582 ms
64 bytes from 10.0.2.52: icmp_seq=399 ttl=64 time=1.875 ms
64 bytes from 10.0.2.52: icmp_seq=400 ttl=64 time=2.040 ms
^C
--- 10.0.2.52 ping statistics ---
401 packets transmitted, 38 packets received, 90.5% packet loss
round-trip min/avg/max/stddev = 1.543/347.812/2202.313/597.164 ms
>

Notice the high response times (normaly it is around 2-200ms) and the massive packet loss in between.

Attachments (0)

Change History (16)

comment:1 Changed 4 years ago by nbd

What kind of Android phone is it?
Are the symptoms still the same in the latest version, or did something change?

comment:2 Changed 4 years ago by anonymous

It is a Jiayu G3S with a MTK6589 processor.
The symptoms are the same with r37855 which I tried yesterday.

As far as I can see the 560-ath9k* patches moved to 300-pending_work.patch as of r37716. I'll try to remove them manually from that file in the latest revision of openwrt to see if the latest version is then working again.

comment:3 Changed 4 years ago by oliver@…

Androis 4.2.1 is running on it by the way.

comment:4 Changed 4 years ago by nbd

Do you have a second ath9k based device that you could use in monitor mode to capture the exchange between the AP and the Client?

comment:5 Changed 4 years ago by oliver@…

Unfortunally I only have this one AP. Additionally I have two mobile phones, and a notebook which are using this AP

comment:6 Changed 4 years ago by nbd

Does your notebook support monitor mode capture?

comment:7 Changed 4 years ago by oliver@…

Uhm... I don't know.
Unfortunally it is a Windows 7 installation. I've tried MS Network Monitor, but it seems I can (beside packages from and to the notepad) only capture Broadcast packets. I can see the Broadcasts from the AP (ManagementBeacon), but my phone shows not up.

comment:8 Changed 4 years ago by nbd

Here are 3 patches that revert parts of the tx queueing rework:
http://nbd.name/900-revert-mcast-sw-queueing.patch
http://nbd.name/901-revert-improve-tx-sched-fairness.patch
http://nbd.name/902-revert-use-sw-queues-for-unaggr.patch
Please try copying them to package/kernel/mac80211/patches one by one starting with the first, running a new test after each one. Let me know if one of those three makes it work for you again.
Thanks!

comment:9 Changed 4 years ago by oliver@…

Thanks for the help so far!

It took me some time to iterate through all 3 possibilities, but I tried them with the following results:

r373864 + 900: problem still exists
r373864 + 900 + 901: problem still exists
r373864 + 900 + 901 + 902: problem gone!

If you want me anything else to do just let me know.

comment:10 Changed 4 years ago by nbd

to futher narrow it down: does the problem exist without the reverts if you disable 802.11n in your config?

comment:11 Changed 4 years ago by oliver@…

With r37855 (=no revert patches, i had this one lying around from my previous tests) and 802.11g enabled, I have no problems.

I noticed by the way, that this mobile in question is the only "n" device I have. The notebook and the other mobile are both "g" devices.

comment:12 Changed 4 years ago by denk

I can confirm the observations made by oliver, see /ticket/14092.html


Thanks to hnyman who kindly provided the test builds I can say the following:

  • 900 doesn't work
  • 900 + 901 doesn't work
  • 900 + 901 + 902 works

comment:13 Changed 4 years ago by nbd

please try current trunk

comment:14 Changed 4 years ago by oliver@…

Tried r37989 and it works like a charm - no problems detected so far. The originally reported connection issues are gone. AP is running on g+n, 40MHz and device is connected with 120MBit/sec

comment:15 Changed 4 years ago by nbd

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

great, thanks for testing.

comment:16 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.