OpenWrt Forum Archive

Topic: Developing Support for TPLINK WDR4900

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

I have 2 cats too, but she likes to search for funny things to do on them (ex. the classic adhesive tape, makes the cat crazy running al the house around, nice fat burner lol )

So, all seems to be related with the HT40 mode?

(Last edited by dabyd64 on 10 Jun 2014, 21:57)

dabyd64 wrote:

I have 2 cats too, but she likes to search for funny things to do on them (ex. the classic adhesive tape, makes the cat crazy running al the house around, nice fat burner lol )

So, all seems to be related with the HT40 mode?

Uhm, nice idea! I've to try the adhesive tape with my fat cat![/OT]



Dunno, for me I need more time to say with certainty..

I'm a little disappointed by this router, coming from a 1043ND with WiFi stability issues I was hoping to finally be able to find a router with some stability ..

Unfortunately, it seems that these open firmwares suffer greatly missed the official drivers .. is a shame to limit a router from 450Mbps to 54Mbps ..

I know! I feel the same, I bought the best Tp-link router to have the newest wireless capabilities and rest in peace for few years, but I don't feel the wifi that fast.

I see that you was using "HT40-". Openwrt now just has HT40, or HT20, no longer has that HT40+/HT40- options

Put this on the console:
cat /sys/kernel/debug/ieee80211/phy*/ath9k/reset

If goes fine, it should  be like this:

    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  0
        MCI Reset:  0
    Baseband Hang:  0
Baseband Watchdog:  9
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  0
        MCI Reset:  0

The repeat when using the HT40 mode. I'll try the HT40 mode myself now

My current testing config:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '48'
        option hwmode '11a'
        option path 'ffe09000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'HT40'
        option noscan '1'

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

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11ng'
        option path 'ffe0a000.pcie/pci0001:02/0001:02:00.0/0001:03:00.0'
        option htmode 'HT40'
        option country 'US'
        option txpower '30'
        option noscan '1'

config wifi-iface
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'MyWifi'
        option encryption 'psk2'
        option key '********'

(Last edited by dabyd64 on 10 Jun 2014, 22:30)

I'm getting around 190Mbit on 5G, syncing at 300MBit.
On 2.4G, its on 170Mbit, syncing at 300Mbit too.
I'll stress it using iperf

dabyd64 wrote:

I'm getting around 190Mbit on 5G, syncing at 300MBit.
On 2.4G, its on 170Mbit, syncing at 300Mbit too.
I'll stress it using iperf

Thanks for these tests.  I am going to a current trunk version soon, and as you note, there have been changes to the underlying configuration, so the info here and earlier is useful.

Ideally, that Ralink misidentification should be bug reported.

@fcecamor: Given the newness of your 2.4 GHz wifi relative to other wdr4900s, it is quite possible that you might see effects others do not.  I have followed the "ath: phy1: Failed to stop TX DMA, queues=0x004!" bug report (and there are other reports  too) and the diversity of responses by different devices is remarkable: from error logged no effects felt; slowing to a crawl, disassociating, to AP disappearing.

I'm guessing that this bug is a bane in the life of dev nbd.

dabyd64 wrote:

My current testing config:

I put your exactly config in my configuration file:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'ffe09000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
#       option txpower '17'
        option htmode 'HT40'
        option noscan '1'
        option country 'IT'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2+ccmp'
        option key '123'
        option ssid 'Wi-CC.net 5.2'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11ng'
        option path 'ffe0a000.pcie/pci0001:02/0001:02:00.0/0001:03:00.0'
        option htmode 'HT40'
        option noscan '1'
        option country 'US'
        option txpower '30'

config wifi-iface
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Wi-CC.net 2.4'
        option encryption 'psk2'
        option key '123'

So I rebooted wifi interface, connected one client and 'puf' just 3 second to get it off and a lot of TX errors in dmesg..

It's really strange..

root@Router:~# cat /sys/kernel/debug/ieee80211/phy*/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  0
        MCI Reset:  0
    Baseband Hang:  0
Baseband Watchdog: 999
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  0
        MCI Reset:  0
root@Router:~#
dabyd64 wrote:

I'm getting around 190Mbit on 5G, syncing at 300MBit.
On 2.4G, its on 170Mbit, syncing at 300Mbit too.
I'll stress it using iperf

Your results are GREAT..

ryts wrote:
dabyd64 wrote:

I'm getting around 190Mbit on 5G, syncing at 300MBit.
On 2.4G, its on 170Mbit, syncing at 300Mbit too.
I'll stress it using iperf

Thanks for these tests.  I am going to a current trunk version soon, and as you note, there have been changes to the underlying configuration, so the info here and earlier is useful.

Ideally, that Ralink misidentification should be bug reported.

Hi Ryts, please, report me if you have the same problem of mine with last trunk..


ryts wrote:

@fcecamor: Given the newness of your 2.4 GHz wifi relative to other wdr4900s, it is quite possible that you might see effects others do not.  I have followed the "ath: phy1: Failed to stop TX DMA, queues=0x004!" bug report (and there are other reports  too) and the diversity of responses by different devices is remarkable: from error logged no effects felt; slowing to a crawl, disassociating, to AP disappearing.

I'm guessing that this bug is a bane in the life of dev nbd.

Why you said my WDR4900 is newness ?
Belive me, I know that bug very good, my 1043ND suffered a lot of that (with dd-wrt) but with last trunk version I get only error in dmesg, very rare instable wifi connection; for this, I escaped to this new router, to don't get the same errors......... mad

(Last edited by fcecamor on 11 Jun 2014, 15:07)

fcecamor wrote:

Why you said my WDR4900 is newness ?
Belive me, I know that bug very good, my 1043ND suffered a lot of this but with last trunk version I get only error in dmesg, very rare instability in wifi connection; for this I escaped to this new router, to don't get the same errors......... mad

I think it was this comment that I then took for granted as correct:

qasdfdsaq wrote:

I suspect it's just defaulting to Ralink Rt3352 because it's the last item in the list, and the list doesn't contain the actual card info because it is too new. Probably a badly designed lookup algorithm or something.

But later I now see someone else confirmed the ralink mis-identification. so your hardware is likely exactly the same. Apologies.

Are you now using the exact same trunk version as dabyd64? There are frequent commits that could affect your issue.

It sucks, I know.  I use a version of OpenWRT called ROOter (for "DirectIP" usb modems) and my wdr4900 became something of a joke as it threw wobblies at a few releases that just worked for other models.  I have stuck so far with one that is stable enough and have speeds of the order reported by dabyd64.

(Last edited by ryts on 11 Jun 2014, 15:16)

ryts wrote:

Are you now using the exact same trunk version as dabyd64? There are frequent commits that could affect your issue.

He's using an old version of trunk, I'm using the yesterday version..

fcecamor wrote:
ryts wrote:

Are you now using the exact same trunk version as dabyd64? There are frequent commits that could affect your issue.

He's using an old version of trunk, I'm using the yesterday version..

I would think that's why he is happy and you are not - something changed . Does he have the bin file that you could use to flash?

BTW: a whole lot of fixes went in, some related to ath9k:

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

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

(Last edited by ryts on 11 Jun 2014, 15:32)

ryts wrote:
fcecamor wrote:
ryts wrote:

Are you now using the exact same trunk version as dabyd64? There are frequent commits that could affect your issue.

He's using an old version of trunk, I'm using the yesterday version..

I would think that's why he is happy and you are not - something changed . Does he have the bin file that you could use to flash?

BTW: a whole lot of fixes went in, some related to ath9k:

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

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

I think it too.. I'll ask him when he will back on the forum smile

My current version is Bleeding Edge, r41062, maybe my problems were fixed, yet ?

fcecamor wrote:

My current version is Bleeding Edge, r41062, maybe my problems were fixed, yet ?

That is possible.

However, the buildbot has not compiled today's so you must wait until it does: http://buildbot.openwrt.org:8010/builders/mpc85xx

Then fetch it from downloads.

ryts wrote:
fcecamor wrote:

My current version is Bleeding Edge, r41062, maybe my problems were fixed, yet ?

That is possible.

However, the buildbot has not compiled today's so you must wait until it does: http://buildbot.openwrt.org:8010/builders/mpc85xx

Then fetch it from downloads.

buildBot wrote:

current activity     waiting
next in
~ 1 hrs 7 mins
at 17:35

Is there anyone who try the new release with me? just to get feedback..

The HT40 dma bugs have been there for at least 2 years, I dont think they fix that so fast.
Are you using it just as an access point? If so I'd suggest to return to stock firmware
I tried yesterday the stock and I'm getting better speeds. 214MBit on 5G, 205Mbit on 2.4G,  and may be limited due the USB 2.0 hard disk!

(Last edited by dabyd64 on 12 Jun 2014, 02:39)

dabyd64 wrote:

The HT40 dma bugs have been there for at least 2 years, I dont think they fix that so fast.
Are you using it just as an access point? If so I'd suggest to return to stock firmware
I tried yesterday the stock and I'm getting better speeds. 214MBit on 5G, 205Mbit on 2.4G,  and may be limited due the USB 2.0 hard disk!

I'm using it also, as an AP.. For me is not essential to get very high speed, stable 'n' wifi is enough..

Can you try with me today's trunk ? Just for a feedback..

Unless you've got the serial cable necessary for fixing things i wouldn't recommend messing around too much with trunk at the moment.  It seems Failsafe and Reset are broken.

I bricked my 4900 upgrading to trunk at the weekend.  It had been happily running a snapshot from last July but that build was missing some packages and i wanted to upgrade to something a little more fresh.

So i configured my backup router (WDR3600) with the same settings (with a few improvements), swapped it for my main router and proceeded with the upgrade.

I unchecked the "retain settings" box and used the sysupgrade image.  After upgrade i logged in via telnet and installed LUCI.  Started and enabled LUCI but was not able to access the Web GUI (http 302 errors).

A quick Google indicated an old version of libuci might be installed and an "opkg list-installed" showed this was the case (along with loads of stale packages from the original snapshot).  Seems that not retaining settings doesn't wipe those old packages too.

Did a "mtd -r erase rootfs_data".  Still old packages.  "No problem" i thought, and did an "opkg upgrade".  Packages were upgraded and i rebooted.  Bricked router.

I tried everything on the WDR4900 Wiki page, but nothing works.  Then i found those tickets above and figured out why.

So now i'm waiting on a serial adapter to try and fix things.

Middling wrote:

Unless you've got the serial cable necessary for fixing things i wouldn't recommend messing around too much with trunk at the moment.  It seems Failsafe and Reset are broken.

I bricked my 4900 upgrading to trunk at the weekend.  It had been happily running a snapshot from last July but that build was missing some packages and i wanted to upgrade to something a little more fresh.

So i configured my backup router (WDR3600) with the same settings (with a few improvements), swapped it for my main router and proceeded with the upgrade.

I unchecked the "retain settings" box and used the sysupgrade image.  After upgrade i logged in via telnet and installed LUCI.  Started and enabled LUCI but was not able to access the Web GUI (http 302 errors).

A quick Google indicated an old version of libuci might be installed and an "opkg list-installed" showed this was the case (along with loads of stale packages from the original snapshot).  Seems that not retaining settings doesn't wipe those old packages too.

Did a "mtd -r erase rootfs_data".  Still old packages.  "No problem" i thought, and did an "opkg upgrade".  Packages were upgraded and i rebooted.  Bricked router.

I tried everything on the WDR4900 Wiki page, but nothing works.  Then i found those tickets above and figured out why.

So now i'm waiting on a serial adapter to try and fix things.

Thanks for your experience Middling,
what version did you installed ?

Middling wrote:

a "mtd -r erase rootfs_data".  Still old packages.  "No problem" i thought, and did an "opkg upgrade".  Packages were upgraded and i rebooted.  Bricked router.

Maybe the correct command was: 'firstboot'; perhaps with 'mtd -r erase rootfs_data' you delete just configuration but not all added packages..

What cable have you ordered ?

No need of a serial cable. Read the wdr4900 wiki, you only need to press reset on boot to enable firmware recovery in the bootloader.Tested myself and worked perfect.

https://forum.openwrt.org/viewtopic.php?pid=236428#p236428


By the way, the mrd -r erase rootfs_data, erases all, not only configs, your router ends completely resetted like just flashed

(Last edited by dabyd64 on 12 Jun 2014, 10:51)

fcecamor wrote:
dabyd64 wrote:

The HT40 dma bugs have been there for at least 2 years, I dont think they fix that so fast.
Are you using it just as an access point? If so I'd suggest to return to stock firmware
I tried yesterday the stock and I'm getting better speeds. 214MBit on 5G, 205Mbit on 2.4G,  and may be limited due the USB 2.0 hard disk!

I'm using it also, as an AP.. For me is not essential to get very high speed, stable 'n' wifi is enough..

Can you try with me today's trunk ? Just for a feedback..

Stock is rock stable for me, openwrt is fine too, but I don't need that for just a simple AP.
Don't get excited with  flashing the Trunk everyday, usually it doesn't make any difference.
You can check the changes done on the changelog:
https://dev.openwrt.org/log/trunk/?mode=follow_copy

(Last edited by dabyd64 on 12 Jun 2014, 10:57)

dabyd64 wrote:
fcecamor wrote:
dabyd64 wrote:

The HT40 dma bugs have been there for at least 2 years, I dont think they fix that so fast.
Are you using it just as an access point? If so I'd suggest to return to stock firmware
I tried yesterday the stock and I'm getting better speeds. 214MBit on 5G, 205Mbit on 2.4G,  and may be limited due the USB 2.0 hard disk!

I'm using it also, as an AP.. For me is not essential to get very high speed, stable 'n' wifi is enough..

Can you try with me today's trunk ? Just for a feedback..

Stock is rock stable for me, openwrt is fine too, but I don't need that for just a simple AP.
Don't get excited with  flashing the Trunk every day, usually it doesn't make any difference.
You can check the changes done on the changelog:
https://dev.openwrt.org/log/trunk/?mode=follow_copy

I use my wrt for VPN, second WLAN network (with firewall rules) and even DLNA (soon) not only AP, for this I don't want to lose the powerful of this firmware..

BTW, read this:

ryts wrote:
fcecamor wrote:
ryts wrote:

Are you now using the exact same trunk version as dabyd64? There are frequent commits that could affect your issue.

He's using an old version of trunk, I'm using the yesterday version..

I would think that's why he is happy and you are not - something changed . Does he have the bin file that you could use to flash?

BTW: a whole lot of fixes went in, some related to ath9k:

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

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

My currently version is r41062 and today's r41148, this fixes are in the middle..

(Last edited by fcecamor on 12 Jun 2014, 11:01)

I was in 41062 too.

Sorry, posts 601 to 600 are missing from our archive.