Jump to content

PriSonerS61

Forum Members
  • Posts

    135
  • Joined

  • Last visited

Posts posted by PriSonerS61

  1. 22 minutes ago, eralde said:

    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)
    image.png

     

    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.

    I don't quite understand your first message. Aren't the "Smart Queue Management" and "Application classification and prioritization" features independent of each other?

     

    I just wanted an on/off feature for the Smart Queue Management feature because it limits the speed according to the value entered. Maybe the user may want to remove or disable it later.

    -------

    Yes I agree with that, if we are not forced to enter integers in mbps, it will indirectly work the same as kbps.

  2. Hello. I think IntelliQoS is missing a few controls. @eralde

    These are : 
    1) Enable / disable
    2) MBPS / KBPS selection

    Feature 1 is needed because : SQM cannot be disabled, there is no control for this in the new interface. When you want to disable it, you cannot enter the value 0 or leave it empty.

    The 2nd feature is needed for the following reason: Sometimes users may want to fine tune the speed in KBPS. I think it would be good to give this choice to the user.

     

    https://ibb.co/mBtd1xD

    sqm.png

    • Upvote 4
  3. 9 minutes ago, eralde said:

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

    Good news. I'm wondering, is the source of the problem related to the interface or something else ?

    Does it have anything to do with the old problem and fix I posted above?

  4. 12 minutes ago, eralde said:

    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.

    In the "show mws member" output, "mode": "11ac". It also appears as "AC" in Selftest. If the data is taken from the "show mws member" output, how can it be wrong on the interface when the "show mws member" output has the correct data ?

    My device is already connected with 5ghz, not 2.4ghz. 5ghz 2x2 80mhz

    In this case, the data in the "show mws member" output matches the "mode" data on the interface of the extender device, but the data on the controller device does not match. 

    Contrary to what you say, the data on the interface of the controller device should be corrected, not the data on the interface of the extender device.

     

    show mws member (controller)

    Spoiler

    "backhaul": {
                    "uplink": "WifiMaster1/WifiStation0",
                    "root": "8000.50:ff:**:**:**:**",
                    "bridge": "8000.50:ff:**:**:**:**",
                    "cost": 50,
                    "ap": "WifiMaster0/Backhaul0",
                    "authenticated": true,
                    "txrate": 702,
                    "uptime": 4264,
                    "ht": 80,
                    "mode": "11ac",
                    "gi": 800,
                    "rssi": -52,
                    "mcs": 8,
                    "txss": 2,
                    "ebf": true,
                    "dl-mu": true,
                    "pmf": true,
                    "security": "wpa2-psk"
                },


    controller

    Spoiler

    controller.png

     

    extender

    Spoiler

    extender1.png

  5. 18 minutes ago, eralde said:

    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.

    Hello. Thank you for your concern. The command "show mws associations" was executed on the "controller" device. Anyway, no response will be returned when this command is written to the extender device.

    In the next hidden message I will tag you and attach the self-test file from both devices.

    show ip hotspot

    Spoiler

    {
                "mac": "50:ff:20:**:**:**",
                "via": "50:ff:20:**:**:**",
                "ip": "192.168.1.2",
                "hostname": "Sprinter",
                "name": "Sprinter (KN-3710)",
                "system-mode": "extender",
                "interface": {
                    "id": "Bridge0",
                    "name": "Home",
                    "description": "Home network"
                },
                "dhcp": {
                    "static": true
                },
                "registered": true,
                "access": "permit",
                "schedule": "",
                "priority": 6,
                "active": true,
                "rxbytes": 1808496,
                "txbytes": 3255177,
                "uptime": 152374,
                "first-seen": 152374,
                "last-seen": 18,
                "http-port": 80,
                "description": "Keenetic Sprinter (NDMS 4.01.A.10.0-0): KN-3710",
                "firmware": "4.01.A.10.0-0",
                "traffic-shape": {
                    "rx": 0,
                    "tx": 0,
                    "mode": "mac",
                    "schedule": ""
                },
                "mac-access": {
                    "Bridge0": "deny",
                    "Bridge1": "deny"
                }
            },

  6. Hi @eralde On the "Wi-fi system" page, the "standard" data appears incorrect.

    On this page it is 802.11N, while on the extender interface and in the "show mws associations" output it is 802.11AC

    There should be 802.11AC everywhere.

    Screenshot-2023-09-30-16-02-03-409-com-m

     

    Screenshot-2023-09-30-16-06-43-585-com-m

     

    show mws associations

    {

        "station": [

            {

                "mac": "*******",

                "ap": "WifiMaster0/Backhaul0",

                "authenticated": true,

                "txrate": 702,

                "rxrate": 867,

                "uptime": 16144,

                "txbytes": 170933203,

                "rxbytes": 1501900948,

                "ht": 80,

                "mode": "11ac",

                "gi": 800,

                "rssi": -53,

                "mcs": 8,

                "txss": 2,

                "ebf": true,

                "dl-mu": true,

                "pmf": true,

                "security": "wpa2-psk"

            }

        ],

        "prompt": "(config)"

    }

    • Thanks 1
  7. 53 minutes ago, shurings said:

    Привет. Обнаружил то же самое после обновления. Отключение питания на роутере ситуации не изменило.

    Помогло переключение ширины канала на 20 МГц и обратно, на 80 МГц.

    Hello. Thank you for the information. Yes, I tried what you said and it indeed solved the problem "temporarily". However, afterwards I "reboot and the problem recurs".

    I have tried this several times and attached the necessary self-test files to my ticket #619661

  8. Hello. If we log out while in the old interface, we are greeted by a blank screen and it stays there. When this happens, various errors occur in the chrome dev. console. I am attaching them as well. This does not happen when logging out of the new interface. Just refresh the page to get rid of this problem. @eralde@Anna Zhelankina

    Normal url : http://192.168.1.1/login?backUrl=%2Fdashboard

    When there is a problem url : http://192.168.1.1/

    • Upvote 2
  9. 17 minutes ago, eralde said:

    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.

    Then I think this feature is a bit ridiculous.

    Our goal is to display the popup in any case.

    This prevents us from seeing more data at first glance and causes unnecessary scrolling.

    I think these pop-ups should be fixed after they are opened, as they were before.

    • Thanks 1
×
×
  • Create New...