Modify

Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#10218 closed defect (fixed)

ar71xx regression

Reported by: Xebec Owned by: nbd
Priority: normal Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: ar71xx, WZR-HP-G300NH Cc:

Description

Looks like one of August or September patches (it took me that long to update my trunk install) of ar71xx introduced a serious regression. All wireless devices connecting to my Buffalo WZR-HP-G300NH experience major problems. This issue was not there in one of the July trunk builds that was installed previously in my Buffalo. Here are some pings of my iPhone4 that was laying about 2 ft from the device:

64 bytes from 192.168.23.14: icmp_req=1 ttl=64 time=506 ms
64 bytes from 192.168.23.14: icmp_req=2 ttl=64 time=2084 ms
64 bytes from 192.168.23.14: icmp_req=3 ttl=64 time=1081 ms
64 bytes from 192.168.23.14: icmp_req=4 ttl=64 time=82.3 ms
64 bytes from 192.168.23.14: icmp_req=5 ttl=64 time=3032 ms
64 bytes from 192.168.23.14: icmp_req=6 ttl=64 time=2037 ms
64 bytes from 192.168.23.14: icmp_req=7 ttl=64 time=1064 ms
64 bytes from 192.168.23.14: icmp_req=8 ttl=64 time=113 ms
64 bytes from 192.168.23.14: icmp_req=9 ttl=64 time=2390 ms
64 bytes from 192.168.23.14: icmp_req=10 ttl=64 time=1388 ms
64 bytes from 192.168.23.14: icmp_req=11 ttl=64 time=434 ms
64 bytes from 192.168.23.14: icmp_req=12 ttl=64 time=50.7 ms
64 bytes from 192.168.23.14: icmp_req=13 ttl=64 time=1713 ms
64 bytes from 192.168.23.14: icmp_req=14 ttl=64 time=706 ms
64 bytes from 192.168.23.14: icmp_req=15 ttl=64 time=211 ms
64 bytes from 192.168.23.14: icmp_req=16 ttl=64 time=1222 ms
64 bytes from 192.168.23.14: icmp_req=21 ttl=64 time=870 ms
64 bytes from 192.168.23.14: icmp_req=22 ttl=64 time=329 ms
64 bytes from 192.168.23.14: icmp_req=23 ttl=64 time=1939 ms
64 bytes from 192.168.23.14: icmp_req=24 ttl=64 time=931 ms
64 bytes from 192.168.23.14: icmp_req=25 ttl=64 time=2466 ms
64 bytes from 192.168.23.14: icmp_req=26 ttl=64 time=1476 ms
64 bytes from 192.168.23.14: icmp_req=29 ttl=64 time=2712 ms
64 bytes from 192.168.23.14: icmp_req=31 ttl=64 time=715 ms
64 bytes from 192.168.23.14: icmp_req=32 ttl=64 time=1926 ms
64 bytes from 192.168.23.14: icmp_req=33 ttl=64 time=927 ms
64 bytes from 192.168.23.14: icmp_req=34 ttl=64 time=27.3 ms
64 bytes from 192.168.23.14: icmp_req=35 ttl=64 time=769 ms
64 bytes from 192.168.23.14: icmp_req=36 ttl=64 time=1402 ms
64 bytes from 192.168.23.14: icmp_req=37 ttl=64 time=405 ms
64 bytes from 192.168.23.14: icmp_req=38 ttl=64 time=184 ms

Here are the pings, when the iPhone is connected to my Linksys E4200 (factory firmware) that is on a different floor, separated by a bathroom, a dining room and a fridge:

64 bytes from 192.168.23.14: icmp_req=12 ttl=64 time=13.6 ms
64 bytes from 192.168.23.14: icmp_req=13 ttl=64 time=18.4 ms
64 bytes from 192.168.23.14: icmp_req=14 ttl=64 time=49.9 ms
64 bytes from 192.168.23.14: icmp_req=15 ttl=64 time=67.5 ms
64 bytes from 192.168.23.14: icmp_req=16 ttl=64 time=90.1 ms
64 bytes from 192.168.23.14: icmp_req=17 ttl=64 time=13.6 ms
64 bytes from 192.168.23.14: icmp_req=18 ttl=64 time=35.1 ms
64 bytes from 192.168.23.14: icmp_req=19 ttl=64 time=59.5 ms
64 bytes from 192.168.23.14: icmp_req=20 ttl=64 time=3.64 ms
64 bytes from 192.168.23.14: icmp_req=21 ttl=64 time=104 ms
64 bytes from 192.168.23.14: icmp_req=22 ttl=64 time=23.2 ms
64 bytes from 192.168.23.14: icmp_req=23 ttl=64 time=49.9 ms
64 bytes from 192.168.23.14: icmp_req=24 ttl=64 time=69.1 ms
64 bytes from 192.168.23.14: icmp_req=25 ttl=64 time=92.8 ms
64 bytes from 192.168.23.14: icmp_req=26 ttl=64 time=13.4 ms
64 bytes from 192.168.23.14: icmp_req=27 ttl=64 time=34.5 ms
64 bytes from 192.168.23.14: icmp_req=28 ttl=64 time=57.1 ms
64 bytes from 192.168.23.14: icmp_req=29 ttl=64 time=22.1 ms
64 bytes from 192.168.23.14: icmp_req=30 ttl=64 time=111 ms
64 bytes from 192.168.23.14: icmp_req=31 ttl=64 time=24.7 ms
64 bytes from 192.168.23.14: icmp_req=32 ttl=64 time=46.9 ms
64 bytes from 192.168.23.14: icmp_req=33 ttl=64 time=69.1 ms

That Linksys is the reason I did not report this problem before - almost all of my devices connect through it. Build 28380 did not fix this issue.

Attachments (0)

Change History (21)

comment:1 Changed 6 years ago by jow

  • Component changed from base system to kernel
  • Owner changed from developers to nbd
  • Priority changed from high to normal
  • Status changed from new to assigned

Ath9k issues?

comment:2 Changed 6 years ago by nbd

try updating to a newer version, there were some fixes that were introduced after r28380

comment:3 Changed 6 years ago by Xebec

Yep, everything is back to normal in 28428. Thank you very much!

comment:4 Changed 6 years ago by jow

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

comment:5 Changed 6 years ago by uzi18@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Still problem with this on TL-MR3420 - trunk from 26.10.2011

$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_req=1 ttl=64 time=3128 ms
64 bytes from 192.168.2.1: icmp_req=3 ttl=64 time=1733 ms
64 bytes from 192.168.2.1: icmp_req=4 ttl=64 time=1712 ms
64 bytes from 192.168.2.1: icmp_req=5 ttl=64 time=1728 ms
64 bytes from 192.168.2.1: icmp_req=6 ttl=64 time=1734 ms
64 bytes from 192.168.2.1: icmp_req=8 ttl=64 time=1749 ms
64 bytes from 192.168.2.1: icmp_req=9 ttl=64 time=1790 ms
64 bytes from 192.168.2.1: icmp_req=12 ttl=64 time=1729 ms
64 bytes from 192.168.2.1: icmp_req=13 ttl=64 time=2235 ms
64 bytes from 192.168.2.1: icmp_req=14 ttl=64 time=1721 ms
64 bytes from 192.168.2.1: icmp_req=16 ttl=64 time=1748 ms
64 bytes from 192.168.2.1: icmp_req=18 ttl=64 time=1780 ms
C
--- 192.168.2.1 ping statistics ---
19 packets transmitted, 12 received, 36% packet loss, time 18076ms
rtt min/avg/max/mdev = 1712.178/1899.205/3128.128/395.214 ms, pipe 4

wireless.radio0=wifi-device
wireless.radio0.type=mac80211
wireless.radio0.macaddr=ZZ:DD:XX:FF:CC:VV
wireless.radio0.ht_capab=SHORT-GI-20 SHORT-GI-40 TX-STBC RX-STBC1 DSSS_CCK-40
wireless.radio0.channel=9
wireless.radio0.country=PL
wireless.radio0.txpower=20
wireless.radio0.hwmode=11g
wireless.@wifi-iface[0]=wifi-iface
wireless.@wifi-iface[0].device=radio0
wireless.@wifi-iface[0].network=lan
wireless.@wifi-iface[0].mode=ap
wireless.@wifi-iface[0].ssid=XXX
wireless.@wifi-iface[0].encryption=psk2
wireless.@wifi-iface[0].key=XXXXXXX

comment:6 Changed 6 years ago by uzi18@…

I'll check trunk r28695 tomorrow.

comment:7 Changed 6 years ago by nbd

please try r28772

comment:8 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

ok, testing ...
Consider add this patch to busybox package:
http://carme.pld-linux.org/~cactus/bin/451-bash_for_gen_build_files.patch

Every update of this package i need to change shell for this script.

comment:9 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

Hmm for first 10 min. I must say looks quiet well, even my android phone have connection now.
Need couple of hours to test. Thanks for patches.

comment:10 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

--- 192.168.1.1 ping statistics ---
32024 packets transmitted, 32020 received, 0% packet loss, time 32064312ms
rtt min/avg/max/mdev = 0.899/7.570/341.231/30.464 ms

comment:11 Changed 6 years ago by nbd

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

comment:12 Changed 6 years ago by nbd

Any comments on why your patch to the gen_build_files.sh script is necessary?

comment:13 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

this script needs bash because errors in finding printf
/openwrt/build_dir/target-mips_r2_uClibc-0.9.32/busybox-1.19.3/scripts/gen_build_files.sh[67]: printf: Argument list too long

GEN include/usage.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/split-include
HOSTCC scripts/basic/docproc

/openwrt/build_dir/target-mips_r2_uClibc-0.9.32/busybox-1.19.3/scripts/gen_build_files.sh[67]: printf: Argument list too long

HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
HOSTCC scripts/kconfig/mconf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf

scripts/kconfig/conf -s Config.in
#
# using defaults found in .config
#

SPLIT include/autoconf.h -> include/config/*
GEN include/bbconfigopts.h
HOSTCC applets/usage

In file included from applets/usage.c:30:0:
include/applets.h:70:1: error: ‘bunzip2_trivial_usage’ undeclared here (not in a function)
include/applets.h:70:1: error: expected ‘}’ before ‘bunzip2_full_usage’
include/applets.h:71:1: error: ‘bzcat_trivial_usage’ undeclared here (not in a function)
include/applets.h:71:1: error: expected ‘}’ before ‘bzcat_full_usage’
include/applets.h:72:1: error: ‘date_trivial_usage’ undeclared here (not in a function)
include/applets.h:72:1: error: expected ‘}’ before ‘date_full_usage’
include/applets.h:74:1: error: ‘id_trivial_usage’ undeclared here (not in a function)
...
...
...

when change to bash ot lanuch ok.

comment:14 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

OK after 20 hour of usage, wifi hangs.
launch wifi script no effect
launch reboot no effect
after disconnect dc power from router for 2 minutes wifi work for a moment:
$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_req=2 ttl=64 time=1763 ms
64 bytes from 192.168.2.1: icmp_req=3 ttl=64 time=1808 ms
64 bytes from 192.168.2.1: icmp_req=7 ttl=64 time=1772 ms
64 bytes from 192.168.2.1: icmp_req=8 ttl=64 time=1762 ms
64 bytes from 192.168.2.1: icmp_req=9 ttl=64 time=1753 ms
C
--- 192.168.2.1 ping statistics ---
11 packets transmitted, 5 received, 54% packet loss, time 10041ms
rtt min/avg/max/mdev = 1753.033/1772.099/1808.851/19.398 ms, pipe 2

It could be related to this issue with switch chip:
http://carme.pld-linux.org/~cactus/bin/ar71xx-switch.patch

need to test this.

comment:15 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

ok your fix for bash works for me ;) thx

comment:16 Changed 6 years ago by nbd

what about the ping issues, are they still there in the latest version?

comment:17 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

ok now i'm sure that problem is with switch driver,
wifi works ok but after switched on laptop connected directly by lan cable to router,
wifi has 1700-3000ms ping and connection by wifi was unusable.
Any hints?
Tests was on clean r28898

comment:18 Changed 6 years ago by nbd

try running tcpdump to see what the laptop is sending. see if it's maybe sending lots of broadcast traffic.

comment:19 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

for me this is this issue: https://lists.openwrt.org/pipermail/openwrt-devel/2011-September/012380.html

any suggestions about tcpdump?

comment:20 Changed 6 years ago by Bartłomiej Zimoń <uzi18@…>

is it possible that /changeset/29026.html fixed my switch issue?

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