eralde

@ru.celebi @PriSonerS61 thank you for the report! We will fix this issue in one of the next Dev versions of the firmware.

Please check if 4.3 Alpha 6.1 solves this problem.

Thank you for the report, that is a bug in Alpha 6. It will be fixed in a future version. That is not a bug. Extender settings that are configured by the controller are locked in the extender web UI. However, at the moment some Wi-Fi parameters are still configurable only via the extender web UI, you can see them if you click on the “Advanced Settings” link in your screenshot. Basic Wi-Fi settings on the extender (SSID / Network protection / Password / ...) in both bands are synchronized with the controller. This is part of the Mesh Wi-Fi system design.

Thank you for the report! This issue was already reported here: It will be fixed in one of the next Dev builds.

Ah, ok, you already created on there as well

Hello, Alex! That actually looks like an issue in the mobile app. There is no "hide KeeneticOS app in the mobile app" setting that the web UI can toggle. I'll move this thread to the section of the forum dedicated to the mobile app.

Hello, I'll pass your request on to the translators

Thank you for the report! We know about this issue and will fix it in the next Dev version of the firmware.

Both the missing text and the fact that it appears on devices with an internal DSL modem will be fixed in Alpha 4.

@Peganeo thanks, we'll check it out. I've hidden your message, so that only moderators can see it.

Please attach the self-test file in a hidden message here. The self-test file can be downloaded on the Diagnostics page.

This is certainly out of scope of this thread (your questions aren't about the Web UI, if I understand them correctly). Please, start a new thread here: https://forum.keenetic.com/forum/52-dev-channel-issues-test-reports/ and describe your issues as detailed as possible or create a new request to the tech support (https://help.keenetic.com/hc/en-us)

The "IntelliQoS" page layout may be a bit confusing, but the "Application prioritization" checkbox actually turns SQM on or off. In order to properly prioritize traffic, we need to: know the actual bandwidth (how many packets you can send per second over a given connection) classify traffic (put packets of a given type into appropriate queues) send a certain number of packets from each queue according to its priority So that's what we show in the new UI: a table to specify the bandwidth limit for each connection, a checkbox to enable classification and another checkbox to enable prioritization (with a list of traffic types that can be ordered according to your wishes below).

To disable traffic prioritization you should uncheck the second checkbox on the picture below (it does the same thing as the toggle in the current UI) Personally, I don't think specifying a kbps limit is a very popular feature, but if it gets a lot of votes, we'll probably implement it. Perhaps an easier way to achieve the same result would be to modify the inputs to allow you to enter a non-integer value (in Mbps) there.

@vst please check this out

https://help.keenetic.com/hc/en-us

No, at this point is looks like the issue is not related to the UI.

Looks like we've found the source of the issue. It will be fixed in one of the future builds.

@Padavan, please, check the provided data.

I apologize, but I misled you. We use data from the show mws member (on the controller) command output do display the Wi-Fi standard in the UI. Still the show mws member command output is present in the self-test file, so I've checked it out. It looks like the controller UI shows the correct standard, there is no 802.11ac for the 2.4 GHz band. https://help.keenetic.com/hc/en-us/articles/213968949-What-you-need-to-know-about-Wi-Fi-5-IEEE-802-11ac- We should fix the standard displayed in the extender UI.

Thank you for the report! We are aware of this issue, it will definitely be fixed in one of the next builds. Please use the Static Routes page in the current UI until it is fixed in the new version.

Please provide the output of the show ip hotspot command on the controller (only the extender device data block is needed), as well as the output of the show mws associations command (is it executed on the extender itself?) and the self-test files from both devices.

For now this is the intended behavior. Interface preference (old vs. new) is not stored anywhere. However, page URLs are different (e.g. /controlPanel/wired vs /wired) so refreshing a certain page should not switch the new interface to the old one. The main dashbord is the exception (/dashboard in both versions).

Thanks for the message! We will fix this issue in one of the next Dev versions. Until this issue is fixed, you can reload the tab in your browser as @dimon27254 suggests.

I've watched your video. This is the expected behavior for the scroll in a popup, not an error. If you find the new scroll behavior inconvenient, please explain why you feel that way.