Marcel,
Thank you for providing this great tool - I'm finding it immensly useful already 
I think, however, the QoS section could do with some attention
Thanks again
I haven't had the chance to test it, I'm reading it today for the first time but for now I have to congratulate you, excellent idea and it seems very valid!
I have followed the details in this thread without needing to configure anything right now. Based on that reading of comments and responses, it appears to be an effective tool with good current responsiveness from the developers. I will try it out later this year.
Whether AI produces effective software depends on the developer, as it always has for any language or development system. Whether a product remains supported depends on the developer, as it always has for any language or development system. Thus, comments about "slop" from possible association with AI assert prejudices rather than reviewing product or otherwise contributing.
If you think Mikrotik hardware / software and the community is slop, you can always move to another product like TP-Link 
Hi Amm0,
Thanks for the kind words! The project isn't open source at the moment. Right now we're fully focused on keeping the quality high, making sure everything runs smoothly, and building the best solution we can.
Maybe somewhere down the line, who knows!
@keithy Both correct, both fixed.
The queue error. dl-voip and ul-voip set limit-at and left max-limit at its default. we had assumed an absent max-limit reads as unlimited on a child. It does not, the check compares literally, hence max-limit less than limit. Every child in the tree now carries an explicit max-limit equal to the parent rate, so a child can still borrow the whole line when the others are idle, and the limit-at guarantees now add up to exactly the parent rate instead of being set on one child and left off the rest. Thank you for pasting it into a real router, that is the only way this gets caught.
The mangle load. Also fair. The old rules matched DSCP, protocol, port and packet size on every single forwarded packet, nine rules deep, which is exactly the wrong shape for a 74K/MIPS box. Rewritten so the expensive matching runs once per connection into a connection mark, with a connection-mark=!no-mark accept at the top of prerouting so an already classified connection leaves after one compare. In steady state a packet now costs one compare in prerouting and at most four in forward. The TCP ACK rule stays per-packet because packet size is not a connection property.
And a warning. Queue tree runs in software and FastTrack is off while it is active, so on the hAP ac generation there is a ceiling around 200 to 300 Mbit/s no matter what line speed you type in. If you pick queue tree on one of those boxes and enter more than 200 Mbit, the tool now says so and points you at fair share with CAKE or fq_codel instead, which is one queue and no mangle rules at all.
Live now. If you have a moment to paste the new output into the hAP ac again I would like to know what it actually does to CPU under load, my numbers above are an estimate rather than a measurement.
I'd disagree with the assertion that "focused on keeping the quality high" if you don't open source the code so it available for inspection.
It's a trivial amount of effort to publish something on GitHub/GitLab, or even a ZIP in forum. So that's a decision, not priority issue. The phrase " fully focused on keeping the quality high" is curious, since code reviews would likely be one of most high value things to solicit, if the goal was actually quality. And, not merely the absence of problem reports to justify the assertion.
If your intent is offering a commercial version, that's fine. It's bait-and-switch that's not. e.g. Let me get the community to do the testing... and the charge down the road charge them. Just be honest.
You should actually read what I wrote, rather than responding with strawman nonsense.
@CGGXANNX While your technicaly right, we formally are not allowing for non-comercial and commercial to make a copy, it is for security reasons we did the setup this way, please don`t promote pirating our software, we are already allowing the use for free.
Thank you!
@Amm0 We just don`t formally allow copying our code and product at this moment for non-commercial or commercial, its as simple as that, and it is our decision, you can say i don`t agree, thats fine but lets agree to disagree, we hope the community has respect for our work and what we are building.
So please don`t pirate our software.
Nowhere I wrote about making a copy. I even wrote that being non open source affects license and distribution which means @Amm0 cannot take your software, make some changes and redistribute it as what normally is usual for open-source licenses.
I wrote that for the purpose of inspecting the software (what @Amm0 wanted) everything is available, and no law forbids that. There is no reverse engineering involved.
Okido Just wanted to be clear.
We are doing some maintenance to the configurator, hopefully back on the 28th
Community Note
This project is not open source. Use your own judgement before contribute to it.
I had/have no intent to do so. My point was just be clear on licensing and use. Right now it's unclear licensing around your work here. e.g. it not actually "Free RouterOS configuration generator"
I was hardly attacking here, and yet being accused of potentially steeling what some have called "AI slop". I was just asking about your intent here. I think a more community oriented solution is what missing in many of these "config generator" projects, not a bunch of one-off me-too solutions. If it ain't open source, it hard to suggest folks waste there time since the learnings then cannot be shared more broadly.
Good, just wanted to be clear, we don`t feel attacked
I can't speak for others, but my experience in overall software quality and desirability is:
Full open source
Closed source
Commercial
YMMV . . . .
If its not open source i don't use it
And that is more then fine.
That's easy to say, but you are using a lot of closed source software, probably the vast majority.
There are many things that have software in them, even your car. Do you only drive cars made before they had computers in them?
I prefer open source, but I can understand why Marcel doesn't want to publish it, because it is a tool they developed for their own internal use. And I apprecaite that he has shared the ability to use it with the community, even without the need for an "account".
And at least up to this point, his team has been very responsive if fixing things that have been found.
Yes, we have been "free" QA testers, but we have also reaped the benefits. How different is this from MikroTik ROS?
I just hope that he doesn't decide to obfuscate as that will make it much harder to trust.
