OpenWrt Forum Archive

Topic: Support for TP-Link Archer C2600

The content of this topic has been archived between 29 Mar 2018 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

antxxxx wrote:

Let me know if there is anything I can do to help with getting the patches for this submitted to the main source, or anything I can help with testing it

I know bendavid would like help getting the patches submitted to mainline. He's tried many times, but keeps having to rework due to "issued" with it (like the title of the email submitting the patches -- I kid you not, and some that are valid), and then he got busy to had to step back a little.

There is also still the problem of pulling all the correct MAC addresses in, but that might have been worked out already.

(Last edited by TeutonJon78 on 10 Mar 2016, 19:20)

The MAC address issue is resolved for the wired interfaces but not yet for wireless.

Currently running arokh's build (r48874). Few caveats;

- MAC address issue like bendavid pointed out still persits.
- 2.4 Ghz 'drops' from time to time. After a few mins appears again.
- Throughput aswell on 2.4 as 5Ghz is not that great. ~20 Mb/s - 400 Mb/s over Wifi AC.
- Router randomly reboots; Last seen message is "ath10k_pci 0001:01:00.0: Unknown eventid: 36898"
- Message: "command failed: Not supported (-95)" randomly pops up in the kernel log.

It still has a few bugs, but even with that: Its still better then the stock TP-Link firmware ;-)

If anyone needs any help with testing or anything, i'd be happy to help out!

(Last edited by blight on 11 Mar 2016, 16:48)

blight wrote:

Currently running arokh's build (r48874). Few caveats;

- Router randomly reboots; Last seen message is "ath10k_pci 0001:01:00.0: Unknown eventid: 36898"

I have noticed loads (over 600 in the last 2 days) of these messsages in the log, but have not had any reboots. Mine has been up for about 30 hours now

I have also seen these messages in the logs

ath10k_warn: 2 callbacks suppressed
failed to transmit packet, dropping: -16

blight wrote:

Currently running arokh's build (r48874). Few caveats;
- Router randomly reboots; Last seen message is "ath10k_pci 0001:01:00.0: Unknown eventid: 36898"

I've the same issue especially when upload and download with max speed.

Flashed r49005 from arokh today ( http://luci.subsignal.org/~trondah/c2600/r49005/ )

- 5Ghz performance upto expectations ( 120.90 Mbps / 12.20 Mbps ) which is the also the max i get through cable (speedtest.net). Connection stable.
- 2.4 Ghz performance somehwat fixed. Downlink speeds still so-so but upload speeds have increased since last build.
- The message "ath10k_pci 0001:01:00.0: Unknown eventid: 36898" still occurs, but it seems that more routers with the same chipset (Linksys EA????) also have this error and they perform fine. Not suspected that this message is related to crashes like antxxx pointed out.

Few other messages in the kernel log that i cant quite figure out:

[  132.710909] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
[  132.711682] ath10k_pci 0001:01:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
[  132.843832] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/cal-pci-0001:01:00.0.bin failed with error -2
[  132.843868] ath10k_pci 0001:01:00.0: Falling back to user helper
[  171.375308] ath10k_pci 0001:01:00.0: qca99x0 hw2.0 target 0x01000000 chip_id 0x003b01ff sub 168c:0002
[  171.375347] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[  171.385199] ath10k_pci 0001:01:00.0: firmware ver 10.4.1.00030-1 api 5 features no-p2p crc32 d2901e01
[  173.432456] ath10k_pci 0001:01:00.0: unable to read from the device
[  173.432487] ath10k_pci 0001:01:00.0: could not execute otp for board id check: -110
[  173.437527] ath10k_pci 0001:01:00.0: failed to get board id from otp: -110, ignoring
[  173.445349] ath10k_pci 0001:01:00.0: failed to fetch board data for bus=pci,vendor=168c,device=0040,subsystem-vendor=168c,subsystem-device=0002 from ath10k/QCA99X0/hw2.0/board-2.bin
[  173.453305] ath10k_pci 0001:01:00.0: board_file api 1 bmi_id N/A crc32 7e56fd07
[  174.853752] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal file max-sta 512 raw 0 hwcrypto 1
bendavid wrote:

The MAC address issue is resolved for the wired interfaces but not yet for wireless.

Im having serious mac address issues using arok's build.  Having a hard time finding a link to your .bin file.

i know people are doing this in their spare time but any update about the wireless / wired mac issue? Happy to help out with testing.

The r49005 runs as expected for the past few days. Perfomance is upto pair and this router's still a blessing, even with the mac issues.

bendavid wrote:

My latest developments are in
https://github.com/bendavid/openwrt/commits/c2600tmp5

The wired MAC issue is fixed there, the wireless MAC is not.

Anything "we" (i.e. non-code devs) can do to help out and get official support for this router?

Hi folks,

I posted this as a new thread, but perhaps those interested directly in the C2600 have a better idea:

How to set 80 MHz channels from the shell:
https://forum.openwrt.org/viewtopic.php?id=63632

Any help you can offer would be great.

Charles

cthulhu5000 wrote:

Hi folks,

I posted this as a new thread, but perhaps those interested directly in the C2600 have a better idea:

How to set 80 MHz channels from the shell:
https://forum.openwrt.org/viewtopic.php?id=63632

Any help you can offer would be great.

Charles

AFAIK in the arokh build the "80 Mhz" channel width is auto-selected. if thats what you want then you just flash it like you normally would do and then its 80 Mhz.

Right, I saw that in LuCI.

I'm going to be running a sniffer, though, and I need to be able to select the bandwidth from the command line.  If LuCI can make the change, then somewhere down in the guts there needs to be something that does the work, and I'm trying to figure that part out.  Perhaps it isn't through the iw command, but I don't know enough about the system to know what that would be.

Charles

cthulhu5000 wrote:

Right, I saw that in LuCI.

I'm going to be running a sniffer, though, and I need to be able to select the bandwidth from the command line.  If LuCI can make the change, then somewhere down in the guts there needs to be something that does the work, and I'm trying to figure that part out.  Perhaps it isn't through the iw command, but I don't know enough about the system to know what that would be.

Charles

You can indeed set these channels with 'iw'.

First find out the capabiltiies of your chipset with

iw phy

Then:

iw dev wlan0 set channel 36 HT80

That should be it.

You can indeed set these channels with 'iw'.

First find out the capabiltiies of your chipset with

iw phy

Then:

iw dev wlan0 set channel 36 HT80

That should be it.

Ok, here's relevant output from iw phy:

    valid interface combinations:
         * #{ managed } <= 1, #{ AP, mesh point } <= 16,
           total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz 

80 MHz is clearly there.  FYI, this is phy0 (wlan0), the 5 GHz radio.  Here's the help output from iw when using the command you suggest:

root@OpenWrt ~# iw dev wlan0 set channel 36 HT80
Usage:    iw [options] dev <devname> set channel <channel> [HT20|HT40+|HT40-]
Options:
    --debug        enable netlink debugging

Clearly, the command doesn't like the HT80 syntax.  11ac is the "very" high throughput phy, so perhaps "VHT80" works:

root@OpenWrt ~# iw dev wlan0 set channel 36 VHT80
Usage:    iw [options] dev <devname> set channel <channel> [HT20|HT40+|HT40-]
Options:
    --debug        enable netlink debugging

Nope.  Here's what the iw command says about setting channel/frequency in its help when you type a wrong command:

    dev <devname> set channel <channel> [HT20|HT40+|HT40-]
    phy <phyname> set channel <channel> [HT20|HT40+|HT40-]
    dev <devname> set freq <freq> [HT20|HT40+|HT40-]
    dev <devname> set freq <control freq> [20|40|80|80+80|160] [<center freq 1>] [<center freq 2>]
    phy <phyname> set freq <freq> [HT20|HT40+|HT40-]
        Set frequency/channel the hardware is using, including HT
        configuration.

So I tried just "80":

root@OpenWrt ~# iw dev wlan0 set channel 36 80
command failed: Invalid argument (-22)

Same result if I try to use the frequency as in

root@OpenWrt ~# iw dev wlan0 set freq 5220 80
command failed: Invalid argument (-22)

My guess is this is the right way to specify in iw, but that the driver is rejecting the values.  FYI, I'm running DD from http://luci.subsignal.org/~trondah/c2600/r49005/

Charles

bendavid wrote:

My latest developments are in
https://github.com/bendavid/openwrt/commits/c2600tmp5

The wired MAC issue is fixed there, the wireless MAC is not.

for us common folk, how can i update from arok's latest build to add your wire mac fix?

justnslayer wrote:
bendavid wrote:

My latest developments are in
https://github.com/bendavid/openwrt/commits/c2600tmp5

The wired MAC issue is fixed there, the wireless MAC is not.

for us common folk, how can i update from arok's latest build to add your wire mac fix?

arokh is already including bendavid's fixes.

Ok i think my issue was i had preserve settings checked.  So now im good to go on the mac address issue.
My new issue is understanding how to properly configure the dnscrypt-proxy.  Can someone tell me how to configure this.  I have given it my best try and i can't seem to change the option resolver value.

I live near Miami, FL in the United States and my resolver appears to be in denmark and is causing major issues.

I have no idea how to post a picture to this site.  When i figure that i will will post a pic.  But basically

root@OpenWrt ~# cat /etc/config/dnscrypt-proxy
config dnscrypt-proxy
    option address '127.0.0.1'
    option port '5300'

    # OpenDNS
    # option resolver 'cisco'

    # DNSSEC enabled and no logging server
    option resolver 'dnscrypt.eu-dk'
   
    # option resolvers_list '/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv'

    # option ephemeral_keys '1'
    # more details at https://github.com/jedisct1/dnscrypt-pr … entication
    # option client_key ''



I want to change the option resolver 'dnscrypt.eu-dk'

So after some research i found that i probably want to use this resolver 'opennic-fvz-rec-us-mia-01'

I have tried doing this from both a mac and a pc with no luck.  I used "vi" and "nano" neither allowed me to save the changes.

Any help would be greatly appreciated.

(Last edited by justnslayer on 29 Mar 2016, 04:45)

NEVERMIND.  Command-O in nano wrote the changes to the file.  I feel pretty dumb now.  Thanks everyone not responding.  That help me rack my brain even more to figure it out.

@bendavid, are these entries in the dts going to conflict?

os-image@1f0000 {
                        label = "os-image";
                        reg = <0x1f0000 0x200000>;
                    };

firmware@1f0000 {
                        label = "firmware";
                        reg = <0x1f0000 0x1d00000>;
                    };

Especially since the sizes are different.

The one from the stock firmware is os-image with base 0x1f0000 and size 0x200000

And for the rootfs partition, not sure if it matters, but the stock name is "file-system". I doubt it does, but just wanted to point it out. It might need to be rootfs for openWRT for all I know.

TeutonJon78 wrote:

@bendavid, are these entries in the dts going to conflict?

os-image@1f0000 {
                        label = "os-image";
                        reg = <0x1f0000 0x200000>;
                    };

firmware@1f0000 {
                        label = "firmware";
                        reg = <0x1f0000 0x1d00000>;
                    };

Especially since the sizes are different.

The one from the stock firmware is os-image with base 0x1f0000 and size 0x200000

I would guess so, since he removed the firmware one already!
You must be looking at an old version? (The commit removing this is from 23 Feb)

Niels

nielsdc wrote:

I would guess so, since he removed the firmware one already!
You must be looking at an old version? (The commit removing this is from 23 Feb)

Niels

Weird, I looked at the raw file, and it showed up there. It must have pulled up the old version, rather than the new one. Good that's it fixed then.

Heinz wrote:

Hi I dump full flash (with factory firmware):
http://tplink-forum.pl/wsady-pamieci-fl … 00v1-5487/

My MAC: EC 08 6B 2C A0 4C, PIN 69842276
MAC location on flash: 0x1EF0008-0x1EF000D
Pin location: 0x1EF0208-0x1EF020F
Device info: 0x1EF0400

Heinz, could you go back to stock and check your MACs for all the interfaces?

LAN/2.4Ghz MAC should be EC 08 6B 2C A0 4B
5GHz MAC should be EC 08 6B 2C A0 4A

If that lines up, then I think we can just assume the default MAC is for the WAN side and the rest are just derived from that one value in flash.

Edit: looking at some of the partitions, the default-config has no mention of the MAC addresses, but the user-config does.

Edit 2: bendavid, ianchi is working on the EA8500 support which is basically the same HW except for the flash bits and seems to be working on the same issues and problems. I'd hate to see any duplicated effort.

(Last edited by TeutonJon78 on 1 Apr 2016, 04:07)

I started using tha same method to extract caldata.
And it also worked for extraction in EA8500.
But the problem I found was when you tried to change the MAC address as that method doesn't recalculate the checksum for the new data accordingly. Then on boot the driver would complain and ended with a crash.
Thus the new package, it adds the checksum recalc.

Today I corrected the place where the script was being called, as previously it was called after the driver loaded, so on first boot it didn't have caldata and so no wifi (on reboot it had the files from previous boot, so eventually it worked).

What specific problem are you having with wifi MAC address? (I haven't followed c2600's thread)

By the way, today I did the first try submitting the patches for inclusion in Trunk.

Yes, my latest code is in
https://github.com/bendavid/openwrt/commits/c2600tmp5

and indeed I removed the extra "firmware" partition.  It wasn't causing any problems, but also wasn't necessary.

@ianchi, yes, I had the same problem changing the wireless MAC address in the calibration data.  Good that you've figured out the issue with the checksum, since that can probably be applied to the c2600 as well.

For the c2600 I confirm that in the stock firmware there is one single MAC address stored in the default-mac partition, and all of the others are derived from that one with increment or decrement.  (But the stock firmware uses the same mac address for LAN and 2.4ghz, which I don't like too much)

Sorry, posts 326 to 325 are missing from our archive.