OpenWrt Forum Archive

Topic: 1043nd 12.09rc1 WIFI drops.

The content of this topic has been archived between 7 Oct 2014 and 27 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.


I have a TP-Link TL-WR-1043nd (version: 1.8) router and I always had problems with the wifi.  I bought this router 6 months ago, and it's firmware was 1.0 (I upgraded it to the latest one), which was more terrible than the OpenWRT. Wifi usually drops my computers when i download or upload with fluently high speed (Max download speed: 5MB/s, Max upload speed: 2.5MB/s). When the router drops down the connected computers none can reconnect to it over wireless connection, but over wired connection everything works correctly (even after the wifi drops). Is this a hardware bug or a software bug? I know people who have the same router with the same problem (but they still have the official TP-Link firmware.) It would be important to make a fix for this. I always have to unplug the router and plug in the adapter of the router, to recover the wifi, or i have to connect to it with a cable and reboot the router in the luci.

I'm waiting for your answer.

Hello Adam,

I have the V1.6 of this router and I'm running Altitude Adjustment B2 and Rc1, both work 100% fine and I really put it under load.

There are no general problems with the 1043 that I know of, hardware or software.
Standard firmware or openwrt firmware.

I suspect your problem is not the 1043, but something else and the situation makes it look like the 1043 is to blame. Especially as you say wired works and wireless does not.

My advise is to complete a site survey, there are free apps on the web to run a complete survey, I'd bet money you'll find that the channels your using on your 1043 are the same channels as all your neighbours. I bet their wifi is getting messed up too!

Silly things like that, or keeping a wireless phone near the router, that really is not a good idea.

Anyway overall point is this, please look outside the router for what could be causing this.

Good luck!

Thank you for the answer. Every Wireless Channel is used by the "neighbours", because i live in a flat. Is this the problem? Changing them doesn't help.

It is worth doing a site survey to find that for sure, I find almost all routers use channel 6, 9 and 2 or 3 (I forget).

When I had similar problems and did a survey I found I had about 17 neighbours all using those three channels, one of which I was using also. I changed to another channel and have never had another problem.

Will it help you for sure, I don't know, but it is well worth trying.

If that doesn't help I have found dropping down a speed helps too.

From n to g or from g to b and so on until you get a steady connection.

If you still think it might be the 1043 maybe borrow a router from family/friend for a few weeks and try that, see if that helps.


i have the same problem here. I have one TL-1043ND and two "TL-WA901ND v2" running at my Network.

All three devices have the same problem. As soon there is more load on Wifi it drops dead. The network is still there but no data come thru (Wired Network runs just fine).

I testet the normal Builds on the server here and compiled also my own builds with the latest svn version for all three devices. Allways the same problem.

On my 1043 i enabled channel 14 to test this. There is no other network on this channel nearby but the problem is still there. After 10 - 30 minutes "heavy" WiFi load it drops and i have to reboot the router (WiFi device itself does not respond to a restart).

I have this problem now for over 5 month and i don't know what to do anymore. I think for the 901 devices i have to go back to DD-WRT. But it would be nice if i can stay with OpenWRT.

Sorry for my bad english.

bye Hausi

(Last edited by Hausmeister on 6 Mar 2013, 11:38)

I'm using wr1043nd too, uptime is several weeks now, device is heavily loaded (I transfer gigs from/to usb storage) over samba. I know there is some kind of bug with atheros and encryption tkip I have had with other devices like wr741nd, but using option encryption 'psk2+ccmp' in /etc/config/wireless seems to solve the problem.

(Last edited by nozombian on 6 Mar 2013, 16:00)

I'm already using the same encryption, and the problem still exists. Here it is a picture about etc/config/wireless:

i'm also using psk2+ccmp ...

config wifi-device 'radio0'
        option type 'mac80211'
        option macaddr '94:0c:6d:ee:81:7e'
        option hwmode '11ng'
        list ht_capab 'SHORT-GI-40'
        list ht_capab 'DSSS_CCK-40'
        option channel '13'
        option country 'DE'
        option txpower '24'
        option htmode 'HT40-'
        option noscan '1'

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'addb-2og'
        option encryption 'psk2+ccmp'
        option network '2og'
        option key 'password'
        option wmm '0'

I tried also turning wmm off and on with no change at all

Do you see something interesting with logread or dmesg, when you experience the bug?

I know there is/was such a bug, but I have not experienced it for a long time with psk2+ccmp. Most of my big file transfers are over lan, wifi devices use mostly internet browsing and downloading, limited by my 16mbit pipe, but less frequently I copy sometimes several big mkvs over wifi too at speeds around 10MB/s.

Hi all,

I also experience similar issue. My router is 1043nd v1.8 + OpenWRT (ATTITUDE ADJUSTMENT (12.09-rc1, r34185)).
My config is as following:

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option macaddr 'f8:d1:11:39:33:78'
        list ht_capab 'SHORT-GI-40'
        list ht_capab 'DSSS_CCK-40'
        option txpower '20'
        option country '00'
        option hwmode '11ng'
        option htmode 'HT40-'
        option channel '9'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid '********'
        option encryption 'psk2'
        option key '********'
        option wmm '0'

I tried different wmm and htmode but problem still persists. Once it is reproduced i will post log and dmesg.

root@OpenWrt:~# uname -a
Linux OpenWrt 3.3.8 #1 Sun Nov 18 04:31:55 UTC 2012 mips GNU/Linux
root@OpenWrt:~# lsmod
Module                  Size  Used by    Tainted: G
option                 14992  0
sg                     18864  0
usb_wwan                6560  1 option
usbserial              23792  2 option,usb_wwan
ath79_wdt               2240  1
ledtrig_usbdev          2032  0
ledtrig_netdev          3184  0
nf_nat_irc               784  0
nf_conntrack_irc        2464  1 nf_nat_irc
nf_nat_ftp               976  0
nf_conntrack_ftp        4416  1 nf_nat_ftp
xt_HL                   1200  0
xt_hl                    720  0
xt_ecn                  1168  0
ipt_ECN                 1264  0
xt_CLASSIFY              496  0
xt_time                 1456  0
xt_tcpmss                912  0
xt_statistic             688  0
xt_mark                  592  0
xt_length                608  0
xt_DSCP                 1360  0
xt_dscp                  912  0
ipt_MASQUERADE           976  1
iptable_nat             2544  1
nf_nat                 10256  4 nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat
xt_recent               5696  0
xt_helper                784  0
xt_connmark              960  0
xt_connbytes            1424  0
pppoe                   7488  0
xt_conntrack            2048  3
xt_CT                   1216  0
xt_NOTRACK               448  0
iptable_raw              560  1
xt_state                 608  0
nf_conntrack_ipv4       4384  6 iptable_nat,nf_nat
nf_defrag_ipv4           656  1 nf_conntrack_ipv4
nf_conntrack           38208 15 nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_helper,xt_connmark,xt_connbytes,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4
pppox                   1152  1 pppoe
ipt_REJECT              1808  2
xt_TCPMSS               2560  1
ipt_LOG                 6160  0
xt_comment               400  0
xt_multiport            1104  0
xt_mac                   528  0
xt_limit                 944  1
iptable_mangle           832  1
iptable_filter           592  1
ip_tables               8864  4 iptable_nat,iptable_raw,iptable_mangle,iptable_filter
xt_tcpudp               1632  5
x_tables                9984 34 xt_HL,xt_hl,xt_ecn,ipt_ECN,xt_CLASSIFY,xt_time,xt_tcpmss,xt_statistic,xt_mark,xt_length,xt_DSCP,xt_dscp,ipt_MASQUERADE,iptable_nat,xt_recent,xt_helper,xt_connmark,xt_connbytes,xt_conntrack,xt_CT,xt_NOTRACK,iptable_raw,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_comment,xt_multiport,xt_mac,xt_limit,iptable_mangle,iptable_filter,ip_tables,xt_tcpudp
ppp_async               5952  0
ppp_generic            18848  3 pppoe,pppox,ppp_async
slhc                    4368  1 ppp_generic
ath9k                  85472  0
ath9k_common            1152  1 ath9k
ath9k_hw              316864  2 ath9k,ath9k_common
ath                    14320  3 ath9k,ath9k_common,ath9k_hw
mac80211              252240  1 ath9k
crc_ccitt                944  1 ppp_async
cfg80211              153696  3 ath9k,ath,mac80211
compat                  5776  5 ath9k,ath9k_common,ath9k_hw,mac80211,cfg80211
arc4                     768  2
aes_generic            29808  5
usb_storage            33152  2
ohci_hcd               16160  0
ehci_hcd               33632  0
sd_mod                 22240  3
ext4                  237824  1
jbd2                   37248  1 ext4
mbcache                 3504  1 ext4
usbcore                99200  8 option,usb_wwan,usbserial,ledtrig_usbdev,usb_storage,ohci_hcd,ehci_hcd
usb_common               480  1 usbcore
scsi_mod               69904  3 sg,usb_storage,sd_mod
nls_base                4640  1 usbcore
crc16                    944  1 ext4
crypto_algapi           9200  2 arc4,aes_generic
ledtrig_timer           1072  0
ledtrig_default_on       416  0
leds_gpio               1552  0
gpio_button_hotplug     3184  0

Do you know if there is existing bug/issue record to track this problem? Thanks

I tested a bit around and disabling HT40 seems to fix it ... at least for some days now. The problem is that the other two devices never were in HT40 mode ... it seems more random ...

I also saw that it dosen't drop the connection complete ... i downloaded a ten Gigabyte testfile and after 30 Minutes it drops down but the download seems to keep going. But only with around 800 kbps. My ping to the first Hop was around 3 seconds.

I also discoverd a new problem with HT40, it might have something to do with this problem.

It seems that HT40- is in reality HT40+ at least in my Build. If i'm using channel 10 and using HT40- it uses 10 + 14. Now the funny part ... if i'm using channel 13 it uses 13 + 17. If i'm using channel 14 the device doesn't even start.

Image channel 10: Link
Image channel 13: Link

The log file doesn't contain any usefull information about the speed drop (realy nothing, and it is set to Debug mode).


It's been 10 days since you post the possible workaround. Can you confirm that this is still working after 10 days?
BTW. I created the ticket to track the issue, please feel free to update it to help it to be resolved. Thanks.

(Last edited by leoha on 23 Mar 2013, 19:20)

I have the same issue on my Asus RT-N13U. I enabled HT40, and it's causing instability. How exactly do I disable that setting from CLI?

config wifi-device 'radio0'
        option htmode 'HT20'

For me  neither HT20 nor HT40+/- works stable sad

We need some kind of status as nothing is suspicious in the log. Suggestions are welcome.

echo iw phy phy0 info> /tmp/wireless-status.txt
iw phy phy0 info >> /tmp/wireless-status.txt
echo iw dev wlan0 info >> /tmp/wireless-status.txt
iw dev wlan0 info >> /tmp/wireless-status.txt
echo iw dev wlan0 station dump >> /tmp/wireless-status.txt
iw dev wlan0 station dump >> /tmp/wireless-status.txt
echo free >> /tmp/wireless-status.txt
free >> /tmp/wireless-status.txt

This is for latter diff with a working state.

mv /tmp/wireless-status.txt /tmp/wireless-bad.txt

Don't wait for me as I only catch this once in a month. But I'd like to collect every useful bit, so please suggest whatever you think will be suspicious.

Do you know any usufull data we can collect from /proc or /sys filesystems?

I tried the router with ht off too like leoha did it, and i have the same opinion: It wasn't stable (it dropped again)! Without HT the speed was a bit lower, beacuse max speed that i was able to reach is 65 mbps.

Just happened today, have a diff...
When works:

iw dev wlan0 info wrote:

Interface wlan0
    ifindex 12
    wdev 0x5

When not:

iw dev wlan0 info wrote:

Interface wlan0
    ifindex 22
    wdev 0xf

Is this any meaningful? Can anyone confirm? I will confirm between a month or less.

BTW iw dev wlan0 station dump is obviously empty, but could be useful as a first suspicious sign.

I don't know but you can post it to the assigned ticket.
BTW For me also HT40- works like HT40+. This is odd.
The issue happened to me again today.
I put logs here

(Last edited by leoha on 26 Mar 2013, 19:32)

I also had an 1043ND rev 1.8 and I tried all possible alternative softwares on it;
on heavy wireless traffic (>5 MB/s) or on large file transfers , it suddenly droped !
the newest firmwares didn't require a reboot, the wlan connection came back after a while, but it was not acceptable as a solution!
I realized that is a hardware problem on certain revisions so I sold it imediatelly ;
strange thing is that, I have a WR941ND which has very similar hardware and wireless chip and it doesn't have this issue on ANY of it's revisions, it's rock stable - I have 12 MB/s wireless transfer on P2P with it as client (same as like on lan cable), WDR3600 being the AP

I guess It's not a hardware issue because on stock firmware I didn't notice any speed drops.
If no solution is found to the issue I will sell the router and buy TL-WDR4300.

(Last edited by leoha on 26 Mar 2013, 20:13)

leoha wrote:

The issue happened to me again today.
I put logs here

You must generate an exact same log when is working too (call it good.txt), so we can run a diff against them both.
Bad.log alone is of little use to non-devs like us.

As far as I have understood, the problems are with AR91xx radio chipsets (AR9106 in 1043ND), especially in noisy environments and HT40. There has been a lot of work in ath9k trying to make these radios reliable, but it looks pretty difficult without input from Qualcomm. Most likely there is a hardware bug which needs to be worked around. Newer revisions of WR941ND, for example, use AR92xx, which works a lot better.

leoha wrote:


It's been 10 days since you post the possible workaround. Can you confirm that this is still working after 10 days?

Let me say ... Yes and No ...

I'm using HT40- on channel 10

        option channel '10'
        option htmode 'HT40-'

So it uses channel 10 and 13. BUT i can only use 1 channel at a time which get me only ~20mbit net. So it is the same as HT20 for me. BUT it is Stable ... no speed drops nor device hangs.

I need to test an Official build to sort out if the HT40- bug is because of my own Build (wrong channel selection). But i have to serve a four party house so i can't test all the time.

My two WA901N v2 Access points are a complete other Story. The first one decided to run now fine with OpenWRT the other which i flashed to DD-WRT softbriked and i had to attach an serial Port to flash the Official Firmware.  Which now runs fine. (I only need OpenWRT on my 1043 for the VLANs). Now i have no SSH anymore but better than nothing.

Bye Hausi

(Sorry for my Bad English)

I can confirm a bad behaviour of wifi too, even with psk2+ccmp. I don't know why or when this happens, but sometimes I really need to do wifi down and wifi to restart wifi. The wifi bug is on multiple models I use - wr1043nd v1.10, wr841nd v8 and wr741nd v4 sad I see the wifi, but I can't login, in this thread is what I have captured so far. Luckily it happens not very often, at least for me, and cron reastarts seem to help. It happens on a link between two devices, where the wifi is not utilised at all and ht20 is used, I have tried recent builds of AA and BB.

(Last edited by nozombian on 15 May 2013, 21:38)