Bug #7833
ipfw will not limit download speed - captiveportal
100%
Description
With a fresh snapshot 2.4.0-RC install, only enabled the captiveportal and set a Default download (Kbit/s).
When I login to the captiveportal I notice it will not limit the download speed, only the upload speed.
It is easy to see this with ipfw table all list:
--- table(cp_ifaces), set(0) ---
em1 2100 273071 268776549 1504184014
--- table(test_auth_up), set(0) ---
192.168.10.100/32 xx:xx:xx:xx:xx:xx 2002 85620 4606692 1504184013
--- table(test_host_ips), set(0) ---
192.168.10.1/32 0 1022 333981 1504184014
--- table(test_pipe_mac), set(0) ---
--- table(test_auth_down), set(0) ---
192.168.10.100/32 xx:xx:xx:xx:xx:xx 2003 0 0 0
--- table(test_allowed_up), set(0) ---
--- table(test_allowed_down), set(0) ---
The table test_auth_down with the auth user has counters at 0
regards
History
#1
Updated by Kill Bill over 3 years ago
Duplicate of Bug #7813. No idea why https://github.com/pfsense/pfsense/commit/5f6825bbac6373a909651c90e8ca268242f6eedc has been reverted.
#2
Updated by Kill Bill over 3 years ago
Related forum threads:
- https://forum.pfsense.org/index.php?topic=136221.0
- https://forum.pfsense.org/index.php?topic=135783.0
Would be good to re-apply the above to fix this regression before 2.4.0 release.
#3
Updated by Jim Thompson over 3 years ago
- Assignee set to Renato Botelho
#4
Updated by Luiz Souza over 3 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Fixed. Please try the next snapshot (will be available on tomorrow's snapshot).
#5
Updated by Kill Bill over 3 years ago
This got reverted yet again. Sigh.
#6
Updated by Renato Botelho over 3 years ago
Kill Bill wrote:
This got reverted yet again. Sigh.
Yes, because kernel was fixed.
#7
Updated by Kill Bill over 3 years ago
Renato Botelho wrote:
Kill Bill wrote:
This got reverted yet again. Sigh.
Yes, because kernel was fixed.
Ah OK, that should be a better fix. ;)
#8
Updated by Vladimir Lind over 3 years ago
[2.4.1-DEVELOPMENT][admin@pf6.localdomain]/root: ipfw table all list
--- table(cp_ifaces), set(0) ---
vmx1 2100 14757 4058636 1506350453
--- table(teagetgb_auth_up), set(0) ---
100.0.1.100/32 00:0c:29:01:9d:9e 2000 3649 544854 1506350453
--- table(teagetgb_host_ips), set(0) ---
10.0.13.115/32 0 0 0 0
100.0.1.253/32 0 1590 249245 1506350450
--- table(teagetgb_pipe_mac), set(0) ---
--- table(teagetgb_auth_down), set(0) ---
100.0.1.100/32 00:0c:29:01:9d:9e 2001 4113 2898621 1506350453
--- table(teagetgb_allowed_up), set(0) ---
--- table(teagetgb_allowed_down), set(0) ---
Not sure what counters to check here, but Speedtest from the authenticated host showed upload as well as download bandwidth corresponding to limits set in CP
#9
Updated by Steve Wheeler over 3 years ago
Confirmed, this looks fixed.
I see limiters created and traffic going into them both up and down:
[2.4.0-RC][root@checkpoint.stevew.lan]/root: ipfw table all list --- table(cp_ifaces), set(0) --- em1 2100 7456 3570847 1506356245 --- table(cplan_auth_up), set(0) --- 192.168.75.10/32 98:5a:eb:11:5b:f5 2000 3348 1452345 1506356245 --- table(cplan_host_ips), set(0) --- 192.168.75.1/32 0 120 14909 1506356139 --- table(cplan_pipe_mac), set(0) --- --- table(cplan_auth_down), set(0) --- 192.168.75.10/32 98:5a:eb:11:5b:f5 2001 3274 1983642 1506356245 --- table(cplan_allowed_up), set(0) --- --- table(cplan_allowed_down), set(0) ---
#10
Updated by Renato Botelho over 3 years ago
- Status changed from Feedback to Resolved
#11
Updated by Kill Bill over 3 years ago
Works here as well. Thanks.