@Clive_A 

Thank your for the update - great news!

Anything you can share about the supported firmware ETA?

Hi  @ITV 

No ETA can be provided. Scheduled to V5.15. That's the timeline.

Note it will be the adapted firmware. Not just about the controller but adapted firmware.

I think in the future, I will be using this to refer to the schedule on the forum. Even if there is a specific time, that's not a guarantee as well. I also need to prepare a disclaimer for that as I cannot guarantee the dev team certainly release firmware at a time point. That's impossible for me as they have other stuff to work on. It may be delayed if something goes wrong.

Please pay attention to the firmware release in the future.

Hi @Spanky66 

Thanks for posting in our business forum.

Spanky66 wrote

  @Clive_A "No ETA can be provided. Scheduled to V5.15. That's the timeline."

 

I understand this position - maybe a small suggestion:  Like Unifi and others, there should be an "Early Access", "Preview" or "Pre-release" ability for those who are willing to try Release Candidate or Beta firmware and software to give constructive feedback!  I know that Omada Controller 5.14 is in Pre-release stage - yet the release schedule and politics at TP-Link are quite inconsstent - thiere needs to be more transparency in the process - Even if it's an estimated release schedule . . . Just my 2 cents ;-)  Looking forward to the ability for disabling NAT on all router products!   :-)

Like I explained some early firmware was designed for certain models for people who really need it. You may contact the support regarding this. However, this implementation does not apply to all the Omada models at this moment. That was customized firmware to only meet certain feature requirements.

When the time comes, if there is a beta published by the dev the beta will be released on the router page and I always notify people about this. If this is not an official beta release, then I cannot make an unauthorized release and that beta only addresses one feature.

We now have pre-release(RC) and beta. In the future, we will implement a beta policy for users instead of posting this publicly. But we barely add new features during the RC or beta phase because a project must be made before the dev starts to work on it. You know, PM > dev > test > ready to be released > RC > official.

We would like to know if the functions in the RC or beta can properly and intentionally work. That would be considered instructive in our position.

As the resources for the dev are not open to us, we cannot get every single detail from them unless they come and respond to the forums. We are two teams and take care of different issues and daily matters. That's how the company works nowadays. Division of work and labor.

Even though there is enough transparency between us, me and the dev, I still have boundaries and confidentiality to observe. Not everything or a roadmap I can let you know about unless it is published by the marketing team which is another team.

And timeline may advance or delay as you know the progress and priority stuff.

Thanks for your insight anyway. Also hope you can understand me and how things work. Hope to make my standing clear.

Hi @Spanky66 

Thanks for posting in our business forum.

Spanky66 wrote

  @Clive_A Thanks for your detailed response!  I fully understand what you are saying . . . and your position

 

This statement says it all:

"As the resources for the dev are not open to us, we cannot get every single detail from them unless they come and respond to the forums. We are two teams and take care of different issues and daily matters. That's how the company works nowadays. Division of work and labor."

 

"Division" is the key word here . . . Development should not work in a vacuum - and marketing should not dictate how the technical feedback channels should work when interested and engaged users in the community are willing to test pre-release stuff and give constructive feedback to help improve the products and expedite wanted features!  That's what I was trying to say about "transparency" - the flow from the user community, technical requests and feedback - and development channels are currently not very transparent.  This request to disable NAT in the Routers has been requested almost 3 years ago . . . 

 

Once again - looking forward to the day I can use my ER605 together with OPNSense as Gateway without double NAT

It was submitted a long time ago which I am aware of. But not until a recent year did we begin to re-evaluate this thing. We don't think this is a proper request at the beginning which was why it took so long. I think I have explained the reason and my colleague @FAE did this, too. Which was "we did not think this is a proper request" as it was designed to be a router and disabling the NAT makes it worth nothing.

Until a year ago, we bean to consider it again and added it to the pool as low-priority. Now it is scheduled and in the roadmap.