Modify

Opened 4 years ago

Closed 3 years ago

#15488 closed defect (no_response)

WDR4900 with additional ath9_htc receives corrupt packets

Reported by: stefan@… Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: kernel Version: Trunk
Keywords: Cc:

Description

For special demonstration purposes, I used to connect an additional USB Wifi module to my TP1043ND connecting the device to an existing wifi network (client mode); with a new WDR4900 device, this configuration does not work anymore:

Plugging in the stick works fine:

[ 1554.309184] usb 1-1.1: new high-speed USB device number 6 using fsl-ehci
[ 1554.418594] usb 1-1.1: ath9k_htc: Firmware htc_7010.fw requested
[ 1554.527469] usb 1-1.1: ath9k_htc: Transferred FW: htc_7010.fw, size: 72992
[ 1554.613213] ath9k_htc 1-1.1:1.0: ath9k_htc: HTC initialized with 45 credits
[ 1555.490710] ath9k_htc 1-1.1:1.0: ath9k_htc: FW Version: 1.3
[ 1555.496330] ath: EEPROM regdomain: 0x809c
[ 1555.496337] ath: EEPROM indicates we should expect a country code
[ 1555.496343] ath: doing EEPROM country->regdmn map search
[ 1555.496349] ath: country maps to regdmn code: 0x52
[ 1555.496355] ath: Country alpha2 being used: CN
[ 1555.496360] ath: Regpair used: 0x52
[ 1555.526425] ieee80211 phy3: Atheros AR9287 Rev:2
[ 1555.534258] cfg80211: Calling CRDA for country: CN
[ 1555.542089] cfg80211: Current regulatory domain intersected:
[ 1555.548082] cfg80211: DFS Master region: FCC
[ 1555.552375] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 1555.562169] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 1555.570322] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 1700 mBm), (N/A)
[ 1555.578413] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s)
[ 1555.586462] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
[ 1555.594497] cfg80211: (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[ 1555.602878] cfg80211: (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)

My configuration:

config wifi-device radio2

option type mac80211
option channel 11
option hwmode 11ng
option path 'soc.0/ffe22000.usb/fsl-ehci.0/usb1/1-1/1-1.1/1-1.1:1.0'
list ht_capab SHORT-GI-20
list ht_capab SHORT-GI-40
list ht_capab TX-STBC
list ht_capab RX-STBC1
list ht_capab DSSS_CCK-40
option htmode HT20


config wifi-iface

option device 'radio2'
option network 'wlink'
option mode 'sta'
option ssid 'MyWifiNetwork'
option encryption 'psk2'
option key 'TheSecretPassword'


config 'interface' 'wlink'

option 'proto' 'dhcp'

(of course the firewall config has been adapted as well)

Bringing up the interface (ifup wlink) works:

Mon Apr 7 20:57:45 2014 daemon.notice netifd: radio2 (4644): command failed: Numerical result out of range (-34)
Mon Apr 7 20:57:47 2014 kern.info kernel: [ 1863.952360] IPv6: ADDRCONF(NETDEV_UP): wlan3: link is not ready
Mon Apr 7 20:57:47 2014 daemon.notice netifd: Interface 'wlink' is enabled
Mon Apr 7 20:57:53 2014 kern.info kernel: [ 1870.200688] wlan3: authenticate with 90:f6:52:e9:c7:ff
Mon Apr 7 20:57:56 2014 kern.info kernel: [ 1872.991504] wlan3: send auth to 90:f6:52:e9:c7:ff (try 1/3)
Mon Apr 7 20:57:56 2014 kern.info kernel: [ 1872.999893] wlan3: authenticated
Mon Apr 7 20:57:56 2014 kern.info kernel: [ 1873.007196] wlan3: associate with 90:f6:52:e9:c7:ff (try 1/3)
Mon Apr 7 20:57:56 2014 kern.info kernel: [ 1873.016620] wlan3: RX AssocResp from 90:f6:52:e9:c7:ff (capab=0x431 status=0 aid=2)
Mon Apr 7 20:57:56 2014 kern.info kernel: [ 1873.084857] wlan3: associated
Mon Apr 7 20:57:56 2014 kern.info kernel: [ 1873.088232] IPv6: ADDRCONF(NETDEV_CHANGE): wlan3: link becomes ready
Mon Apr 7 20:57:56 2014 daemon.notice netifd: Network device 'wlan3' link is up
Mon Apr 7 20:57:56 2014 daemon.notice netifd: Interface 'wlink' has link connectivity
Mon Apr 7 20:57:56 2014 daemon.notice netifd: Interface 'wlink' is setting up now
Mon Apr 7 20:57:56 2014 daemon.notice netifd: wlink (4715): udhcpc (v1.19.4) started
Mon Apr 7 20:57:56 2014 daemon.notice netifd: wlink (4715): Sending discover...
Mon Apr 7 20:57:59 2014 daemon.notice netifd: wlink (4715): Sending discover...
Mon Apr 7 20:57:59 2014 daemon.notice netifd: wlink (4715): Sending select for 192.168.206.66...
Mon Apr 7 20:58:02 2014 daemon.notice netifd: wlink (4715): Sending select for 192.168.206.66...
Mon Apr 7 20:58:05 2014 daemon.notice netifd: wlink (4715): Sending select for 192.168.206.66...
Mon Apr 7 20:58:08 2014 daemon.notice netifd: wlink (4715): Sending select for 192.168.206.66...
Mon Apr 7 20:58:08 2014 daemon.notice netifd: wlink (4715): Lease of 192.168.206.66 obtained, lease time 43200
Mon Apr 7 20:58:08 2014 daemon.notice netifd: Interface 'wlink' is now up

But transmitting actual data proves difficult, due to a great amount of packet loss. Inspecting the interface via tcpdump yields disturbing data:

20:59:17.995859 00:15:58:ce:a2:60 Unknown SSAP 0xe2 > 1c:4b:d6:55:64:50 Unknown DSAP 0x08 Information, send seq 0, rcv seq 16, Flags [Response], length 108
20:59:18.467377 5c:a3:9d:2d:df:84 Unknown SSAP 0xa8 > 90:18:7c:db:50:63 Unknown DSAP 0xc4 Information, send seq 0, rcv seq 16, Flags [Response], length 84
20:59:18.478100 5c:a3:9d:2d:df:84 Unknown SSAP 0xa8 > 90:18:7c:db:50:63 Unknown DSAP 0xc6 Information, send seq 0, rcv seq 16, Flags [Response], length 76

Looks like the data is somehow corrupted. Plugging everything back into the old TP1043 works fine, so there must a catch with the WDR3900 and the USB module.

root@delta:~# cat /proc/cpuinfo
processor : 0
cpu : e500v2
clock : 799.999992MHz
revision : 5.1 (pvr 8021 2151)
bogomips : 99.99
timebase : 49999999
platform : Freescale P1014
model : TP-Link TL-WDR4900 v1
Memory : 128 MB
root@delta:~# cat /etc/openwrt_release
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="Bleeding Edge"
DISTRIB_REVISION="r40396"
DISTRIB_CODENAME="barrier_breaker"
DISTRIB_TARGET="mpc85xx/generic"
DISTRIB_DESCRIPTION="OpenWrt Barrier Breaker r40396"
DISTRIB_TAINTS=""
root@delta:~# uname -a
Linux delta 3.10.34 #1 Mon Apr 7 00:05:32 PDT 2014 ppc GNU/Linux

Attachments (0)

Change History (3)

comment:1 Changed 4 years ago by stefan@…

The issue seems to be WPA2 related - connecting the USB wifi dongle to an open network yields far better results, while using encryption still garbles most packets (a few get through though).

Any ideas?

comment:2 Changed 3 years ago by nbd

is this still an issue in current trunk?

comment:3 Changed 3 years ago by nbd

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

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.