eralde

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.

I can't reproduce this. I may have misunderstood the nature of the issue. Either the page or the popup window is scrolling for me (this works the same way on all UI pages). Please describe what you are doing step by step. E.g.: <I am using the "X" browser in the "Y" OS on my computer/smartphone/... (exact build version aren't required, for example "Windows 10/Chrome" is enough)> I open the "Client Lists" page I press the "BUTTON" button on my keyboard / I click on the ... element on the page / I scroll the page using the mouse / ... ... then I <do something else> ... ... (a few more steps) ... then Z happens, which I think is the problem

@Anna Zhelankina

The base language of the UI is English. When new functions are introduced, the texts for them will be in English only. Over time they will be translated into other languages, including Turkish. This is not a problem for the Dev firmware. Please attach the self-test file or the startup-config file in a hidden message to this thread.

Thank you, we'll fix that in one of the next releases.

Thanks for the report, we are working on fixing this issue.

With 10.34.5.0/27 you have 30 usable addresses max (10.34.5.1 - 10.34.5.30), if you set the starting address to 10.34.5.10 it reduces the max pool size (then the largest pool is 10.34.5.10-10.34.5.30). Maybe we should extend the available sizes range by 1 (1...21), but I'm glad that both versions of the UI agree in validation.

Looks like an error in the current ("old") UI. Could you remember the exact order of changes in the settings that lead to this (e.g. 1. change the IP address field, 2. change the mask, 3. ...)? I've tried to reproduce the issue with your settings and both versions show that the pool size is too large:

It is still in development. Thank you for reminding me about this!

Thank you ) We'll continue to work on it, there's still a lot to do This is definitely a bug. Will be fixed in the next version. The new UI should not be available on extenders at all. For the moment it was tested only on devices in the Router mode. I think that this issue (along with many others) will be fixed once we develop the new UI for extenders. Looks like the part of the same issue for non-Router modes. This part is still under development Yeah, we need to do something with this. I agree that on mobile devices dashboard is inconvenient to use right now.

@vst прокомментируй, пожалуйста

Видимо, валидация в веб-интерфейсе работает кривовато. Система строчку "/127" конечно не принимает как корректный префикс. Заведу задачу на исправление. Для корректных значений всё задается и выводится нормально:

Какой префикс вы вводите в попае Connection settings?

It may be counterintuitive, but the show ping-check command show the status of the ping-check profile. I don't know why it doesn't show the configured min-success value, but you can verify that it is stored in the configuration by executing show rc ping-check : (config)> show rc ping-check (config)> ping-check profile test PingCheck::Client: Profile "test" has been created. (config-pchk)> min min-success - set the min success count (config-pchk)> min-success 8 PingCheck::Profile: "test": uses 8 success count for enabling interface. (config-pchk)> max- max-fails - set the maximum fail count (config-pchk)> max-fails 3 PingCheck::Profile: "test": uses 3 fail count for disabling interface. (config-pchk)> mode icmp PingCheck::Profile: "test": uses icmp mode. (config-pchk)> host 1.2.3.4 PingCheck::Profile: "test": add host "1.2.3.4" for testing. (config-pchk)> exit Core::Configurator: Done. (config)> show rc ping-check config, name = ping-check: config, name = profile: name: test config, name = host: host: 1.2.3.4 config, name = mode: mode: icmp config, name = min-success: count: 8 config, name = max-fails: count: 3 (config)> show ping-check pingcheck: profile: default pingcheck: profile: test hosts: 1.2.3.4 max-fails: 3 mode: icmp Generally, the show rc <...> command will print out a part of the current configuration (running-config) related to <...> (e.g. show rc interface Home)

@vst, would you please check this out?

Uncheck the "Auto-mount new USB drives" checkbox to disable this behavior.