@John1234 

No it is a bit more complex than that the MTD3 partition contains fie that need to be modified, you can only change from USA to EU mode.

Here is what I don't get...

In the USA  ALL CHANNELS (UNII, UNII2, UNII2-e, UNII-3) are available to use to the public - So why does TP Link REFUSE to use them?  Cisco uses them, Aruba uses them -

In fact, any "REAL" wireless system in the US makes all of these channels available.

I work for one of the largest healthcare providers in the US - WE HAVE to enable all the channels we can, in fact, we have to reduce our channels to only 20 MHz overlap just because of the volume of devices/AP we need.

I've posted this in the TP-Link forum before, but they clearly don't care.

TP LINK - LEARN THE US - we allow ALL UNII-1, UNII-2, UNII-2e, UNII-3  (DFS just means to you need to back of if radar is detected.) 

Are you not able to compete like other companies and figure out a way to move off DFS  if it's detected?  FYI, in the research of over 40,000 AP's over the course of several months, we only found 3 (three, yes three) instances where there was DFS events were detected.  NOT A BIG DEAL. 

WelshWizards wrote

TP-link cant code it seems.

Openwrt is by far not bugfree too, does it mean their developers can't code? According to you, openwrt contributors can not code a line, right? I liked previous posts but find this one personally out of touch in case that you really can code and play with hardware, you could have downloaded controller software and everything else to check, you could have read multiple posts about DFS not available for US. Knowing that there is no DFS on US version, you could have ordered either EU version if it has to be tplink or buy simply another device, you could have checked specifications, ... . How did you miss it all? How did you buy a device without DFS support where you required one? Discussion is leading to nowhere if tp-link replies that it is your fault that you can not read because you bought that product, how would you like such reply? I get that you are not satisfied with the product, you should have brought back to the store like you said, but then you decided to keep it and flash it with openwrt, at the you flash it with openwrt, seem to be satisfied and claim that tp-link can't code. How do you know at all that tp-link coded it and not outsourced to another company? Tell me which commercial products did you develop and if there is a single bug or incompatibility, then you probably should write under that product that you can't code, right?

Thinking is not knowing, but you seem to know. Do you know if tp-link at all developed it all alone or if it was outsourced? And how does it come that you waste so much time on that one device but you did not waste any time on reading specifications of devices and it's firmware?

You maybe should have written your comment to tp-link support instead of posting such arrogant comment in community forum.

If you are a dev, I am really sorry for your colleagues

  @btx 

I dont think i have ever said that the OpenWRT devs are unable to code, some serious brains on that team.

The EAP245v3 has been artifically limited in capability, the radio supports all the global 2.4Ghz/5Ghz ranges. For some inexplicable reason tp-link only chose to produce radio firmware for US/EU regions. 

Regardless of DFS support, the device doesnt even support all the non DFS channels in my locale.

  @WelshWizards if it is artificially limited in capability, then there must be a reason, one could be simply cost reduction, another could be simply not expanding investment in software development and as far as I know, tp-link is not really software developing house. What the real reasons are, I do not know as I never asked, but my feeling tells me that you can direct your request officially to tp-link from where you would get a reply why it is artificially limited. I am also not sure about DFS in US and why they do not offer it, maybe something is not certified or some hardware, but here again, I guess you would get very exact reply from support, I did not ask them that question and by that I do not know the answer. It is very nasty if DFS is not available and I probably would give the device back instead of using openwrt with it as I am not so sure that wireless drivers are stable and there are no issues, however, you can always revert back, I did not have US version in my hands but assume that hardware is the same as EU's.

I did run openwrt on eap245v3 EU for a test, it worked ok, but there were several issues, I reverted it back to original. Currently omada lacks on dhcp reservation which does not work and many other smaller or bigger bugs seem to persist over time, guess they have enough to do.

Fae seems to have replied that it is not supported and I could not filter out that it will be supported (artificially or not), I probably would simply return that device and replace it with either some eap supporting dfs channels in US or simply another brand if there is no tp-link device with dfs for US.