Project

General

Profile

Actions
Copy link

Bug #7833

closed

ipfw will not limit download speed - captiveportal

Added by Azure it about 7 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
High
Assignee:
Renato Botelho
Category:
Captive Portal
Target version:
2.4.0
Start date:
08/31/2017
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.x
Affected Architecture:

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

Actions
Copy link
 #1

Updated by Kill Bill about 7 years ago

Actions
Copy link
 #2

Updated by Kill Bill about 7 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.

Actions
Copy link
 #3

Updated by Jim Thompson about 7 years ago

  • Assignee set to Renato Botelho
Actions
Copy link
 #4

Updated by Luiz Souza about 7 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).

Actions
Copy link
 #5

Updated by Kill Bill about 7 years ago

This got reverted yet again. Sigh.

Actions
Copy link
 #6

Updated by Renato Botelho about 7 years ago

Kill Bill wrote:

This got reverted yet again. Sigh.

Yes, because kernel was fixed.

Actions
Copy link
 #7

Updated by Kill Bill about 7 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. ;)

Actions
Copy link
 #8

Updated by Vladimir Lind about 7 years ago

[2.4.1-DEVELOPMENT][]/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

Actions
Copy link
 #9

Updated by Steve Wheeler about 7 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) ---
Actions
Copy link
 #10

Updated by Renato Botelho about 7 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #11

Updated by Kill Bill about 7 years ago

Works here as well. Thanks.

Actions
Copy link

Also available in: Atom PDF