[Bug] Rate Limit (Download/Upload) settings on Local Users have no effect
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Rate Limit doesn't seem to have an effect on local users.
More info:
1. I set a wifi ssid with local user authentication.
2. I added my username/password without Rate Limit.
3. Connected my phone on wifi as Local User.
4. I edited local user's rate limit, 2mbps download and 1mbps upload.
5. Then I did run a speedtest.
And this is what happened. Speedtest shows max speed for both download and upload, ignoring my local user's rate limit.
Or does setting Rate Limit for local users only affect newly connected machine?
Does changing this setting doesn't affect those that are already loggedin while rate limit was still unlimited?
I tried reconnecting my device via Controller, and device's speed was still unlimited.
I tried turning OFF device's wifi, turn it back on, run a speedtest again, and device's speed was still unlimited.
If this is the case, what then is the purpose of having to edit an existing user's rate limit?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
hashrack wrote
Okay. So I read your brief explanation and seems like it's not a bug at all. It just needs more steps to apply rate limit on local users which is:
- to unauthorize the device, have them reauthenticate to apply the changes- to reboot the AP (as I have tested and work, without reauthentication).
Yes. The difference between rate-limiting a user session and rate-limiting the SSID/a device is that the former rate-limit is bound to the session and will be activated at login time of such sessions for any device the user uses, while the latter is bound to a SSID/a device and will be activated either at the time the settings change (SSID rate-limit) or the device connects to the WLAN (device rate-limit).
The reason for this design is the implementation for the intented policy:
If session rate-limits are changed, a session might not exist yet or there might be one, two or more active sessions from this user on different devices. So, session parameters need to be activated at login time when the auth mechanism determines the device the user is using for a given session. Then the rate-limits are bound to the device the users uses for this session in order to activate them. There might be more sessions from the same user at the same time, so this is the correct place to activate the limits.
Imagine following situation (and keep in mind that the WiFi layer just sees devices, not users):
- There is a SSID rate-limit active currently. This is active all the time for all devices connecting to this SSID.
- Now device X connects. If there is a device rate-limit, it will now become active. The WiFi layer has no idea anymore about the values of SSID limits for this single device.
- Now, on device X user Y logs in. If there is user rate-limit, it will now become active. The WiFi layer has no idea anymore about SSID/device limits for this single device.
It's the same policy used for other settings such as global session expiration and user-related session expiration or even a modified user's password (most obviously!).
Hope this now makes more sense to you why a specific order in applying rate-limits must be followed if such a policy is defined for a single ressource such as rate-limits of a WiFi chip.
- Copy Link
- Report Inappropriate Content
@hashrack, please see this thread: https://community.tp-link.com/en/business/forum/topic/185056 for the solution.
Long story short:
- Avoid »smart« phones when doing speed tests (they are too smart),
- or alternatively turn off mobile data when doing tests,
- use a professional test tool such as iperf.
- Copy Link
- Report Inappropriate Content
R1D2 wrote
@hashrack, please see this thread: https://community.tp-link.com/en/business/forum/topic/185056 for the solution.
Long story short:
- Avoid »smart« phones when doing speed tests (they are too smart),
- or alternatively turn off mobile data when doing tests (according to your screenshot you didn't),
- use a professional test tool such as iperf.
Mobile data is turned OFF. If it's ON, it should display LTE or 3G or Edge, not the WiFi icon.
Other than that, my WiFi's internet provider is SMART. My phone's provider is GLOBE. That's why it's showing GLOBE then WiFi icon on the phone. And speedtest shows SMART as provider.
Anyway, got it figured out.
Chaging Rate Limit on Local User doesn't take effect unless device (on my case, EAP225-Outdoor) is rebooted.
I guess this is a bug after all. As the Rate Limit update don't take effect, for existing/already connected device, unless the AP (EAP225-Outdoor) is rebooted.
- Copy Link
- Report Inappropriate Content
@hashrack, I was referring to smart behavior of smartphones, not SMART provider. Smartphones fall back to mobile data if WiFi signal is bad or throughput too low. The speedtest server determines the provider when connecting, if the smartphone then changes to mobile data, speedtest can get confused about the provider. That's why you always should use a test program such as iperf which is available for mobile phones, too. It let's you control the test much better than speedtest apps do.
Anyway, rate limiting works for me without a reboot of the EAP (tested).
- Copy Link
- Report Inappropriate Content
im referring to my screenshot, the providers.
no need to reboot on changing limit on device and on ssid.
but needs a reboot when changing limit from local user.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
hashrack wrote
no need to reboot on changing limit on device and on ssid.
but needs a reboot when changing limit from local user.
No, that's simply wrong, sorry. Tested it as follows:
1. Did set up SSID & portal with local user accounting.
2. Added user account w/o rate limit.
3. Logged in, tested WiFi throughput with iperf:
$ iperf -c 192.168.1.10
Client connecting to 192.168.1.10, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.205 port 52663 connected with 192.168.1.10 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 20.0 MBytes 16.7 Mbits/sec
$
4. Set rate limit for this user to 200 Kbps down/up (NOT device nor SSID rate limit!).
5. Now did unauthorize the current user session, logged in again.
6. WiFi throughput is now rate-limited:
$ iperf -c 192.168.1.10
------------------------------------------------------------
Client connecting to 192.168.1.10, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.205 port 52727 connected with 192.168.1.10 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-14.2 sec 384 KBytes 222 Kbits/sec
$
7. Speedtest via tablet on dslreports.com, since speedtest.net is too weird IMO (would force me to install an app):
Conclusion: no reboot needed, no bug in Omada controller nor EAP.
- Copy Link
- Report Inappropriate Content
I don't want to "unauthorize" the current user session. If I did, I have to enter username/password on those 2 Android phones that I wanted to modify rate limit.
WiFi SSID's rate limit and Device's Rate Limit doesn't need reboot or "unauthorize" to apply the rate limit. On both mentioned, after rate is applied, it's applied automatically.
But if I change rate limit on local user, it doesn't automatically apply the limit, unless EAP is rebooted, or as you mentioned, "unauthorize" the device.
Yes, your conclusion: no reboot needed, no bug in Omada controller nor EAP. But you did "unauthorize" the device and login again, entering username/password again.
Test again from 1 to 6, skipping #5. And you'll see what I mean. Rate is not applied unless device is "unauthorized" (as per your test) or EAP is rebooted (as per my test).
That is my main point. Why rate limit is not automatically applied unless device is "unauthorized" or EAP is rebooted.
As mentioned above, Device Rate Limit nor SSID rate limit change don't need to "unauthorize" devices nor reboot anything to apply the new rate limit, its automatically applied.
Anyway, to skip the hassle of rebooting EAP or unauthorize devices and logging them again, if I wanted to change the local user's rate limit, I just disable the feature and not use it at all (Local User Authentication).
Perhaps my explanation is not good enough to convince anyone, why I think this is a bug on local user's rate limit, then I just stop using this particular feature and use something else that works for me. As much as possible, I don't want to reboot device (as it will take 3 to 4 minutes before it's online again) or unauthorize devices (then login again) just to apply rate limit.
- Copy Link
- Report Inappropriate Content
I don't need to test it without Unauthorize step 5 to know how rate-limiting is working. I'm a software engineer for WiFi hotspots for 15 years now and as such I developed rate-limiting functions for hotspots like those implemented in Omada controller for our own Wireless Captive Portal running on several different hardware platforms with different WiFi chips including those used in TP-Link products.
I'll be brief:
- One doesn't need to unauthorize the device, one needs to to unauthorize the user session. That's what happens if you click on the »Unauthorize« button.
- A user session always needs to be unauthorized to activate any session-related settings changed after start of a user session. Such settings will be active during the whole session.
- If you choose Local User authentication, hotspot users will have to re-authenticate themself anyway every time after:
- they manually log out from the user session,
- their user session got unauthorized by the admin
- or the user session expires.
- Thus, user sessions will always get unauthorized automatically, at least after the session expired.
- The user needs to type the password again to log in after the session did expire. That's how Local User authentication on WiFi hotspots is supposed to work. New session settings take effect for the next session. That's why there is an »Unauthorize« button in the client list: to force session expiration and to force new session settings to take effect. What's the problem with this? And how often do you change rate-limits during a session? Five times each day?
If you don't like this for rate-limiting your two Android devices, don't use Local User rate-limiting and consider to use device rate-limits.
- Copy Link
- Report Inappropriate Content
Okay. So I read your brief explanation and seems like it's not a bug at all. It just needs more steps to apply rate limit on local users which is:
- to unauthorize the device, have them reauthenticate to apply the changes
- to reboot the AP (as I have tested and work, without reauthentication).
Since it doesn't work the way I want it, I just stopped using it. As for the 2 Android Devices that I frequently modify their rate limits, depending on different situation, I just created a separate SSID (with password but without portal) and only those 2 devices can connect. This way, if I wanted to change rate limit on those 2 device, I just change it directly from SSID. No need to reauthenticate, no need for reboot.
As per your suggestion to limit via device rate limit, that would be easy if it we're some other android phones which have hostnames like "android-***** (some numbers and letters)".
But my problem is, these specific phones uses hostnames "OPPO-A5s". All oppo-a5s displays hostnames as oppo-a5s. I can't tell which oppo-a5s that I wanted to modify rates. And I have several devices (not mine, but customer's device) that also displayed as oppo-a5s.
So I just create a separate SSID just for these specific oppo device that I wanted to change limit from time to time.
The reason why I thought it was a bug is that it doesn't work the way I wanted it to be, or as expected it to be. Changing rate limit on SSID and Device doesn't need additional steps. I just change rate limit, press OK and it's done. I thought the Local User would do the same. And since it acts differently, I thought it was a bug.
And since it doesn't work the way I wanted it to, I stopped using that feature.
- Copy Link
- Report Inappropriate Content
hashrack wrote
Okay. So I read your brief explanation and seems like it's not a bug at all. It just needs more steps to apply rate limit on local users which is:
- to unauthorize the device, have them reauthenticate to apply the changes- to reboot the AP (as I have tested and work, without reauthentication).
Yes. The difference between rate-limiting a user session and rate-limiting the SSID/a device is that the former rate-limit is bound to the session and will be activated at login time of such sessions for any device the user uses, while the latter is bound to a SSID/a device and will be activated either at the time the settings change (SSID rate-limit) or the device connects to the WLAN (device rate-limit).
The reason for this design is the implementation for the intented policy:
If session rate-limits are changed, a session might not exist yet or there might be one, two or more active sessions from this user on different devices. So, session parameters need to be activated at login time when the auth mechanism determines the device the user is using for a given session. Then the rate-limits are bound to the device the users uses for this session in order to activate them. There might be more sessions from the same user at the same time, so this is the correct place to activate the limits.
Imagine following situation (and keep in mind that the WiFi layer just sees devices, not users):
- There is a SSID rate-limit active currently. This is active all the time for all devices connecting to this SSID.
- Now device X connects. If there is a device rate-limit, it will now become active. The WiFi layer has no idea anymore about the values of SSID limits for this single device.
- Now, on device X user Y logs in. If there is user rate-limit, it will now become active. The WiFi layer has no idea anymore about SSID/device limits for this single device.
It's the same policy used for other settings such as global session expiration and user-related session expiration or even a modified user's password (most obviously!).
Hope this now makes more sense to you why a specific order in applying rate-limits must be followed if such a policy is defined for a single ressource such as rate-limits of a WiFi chip.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 3515
Replies: 10
Voters 0
No one has voted for it yet.