Project

General

Profile

Actions

Regression #13488

closed

All Captive Portal users are given the same limiter pipe pair

Added by Steve Wheeler about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Very High
Category:
Captive Portal
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
Affected Architecture:
All

Description

When the captive portal is configured to use a per-user bandwidth limit individual pipes are supposed to be created for each user.

In 22.05 the same pipes are being used for all users. So however many connect you see:

[22.05-RELEASE][admin@2100-3.stevew.lan]/root: dnctl pipe show
02000:   5.000 Mbit/s    0 ms burst 0 
q133072 100 sl. 0 flows (1 buckets) sched 67536 weight 0 lmax 0 pri 0 droptail
 sched 67536 type FIFO flags 0x0 16 buckets 0 active
02001:  10.000 Mbit/s    0 ms burst 0 
q133073 100 sl. 0 flows (1 buckets) sched 67537 weight 0 lmax 0 pri 0 droptail
 sched 67537 type FIFO flags 0x0 16 buckets 0 active

This means that all users have to use that limited bandwidth between them.

It also means that when a user is disconnected the pipe pair is deleted and all users are unable to pass traffic. This can happen either via a manual disconnect or via a timeout.

When a new user authenticates the one pipe pair is recreated allowing any other users to connect again.

Anything else that recreates it will also appear to restore connectivity. Resaving the CP settings for example.

This issue encompasses these existing bugs:
https://redmine.pfsense.org/issues/13475
https://redmine.pfsense.org/issues/13477

Tested in:

22.05-RELEASE (arm64)
built on Wed Jun 22 18:56:18 UTC 2022
FreeBSD 12.3-STABLE


Related issues

Related to Bug #13475: Captive Portal per-user limiters malfunctionDuplicateKristof Provost09/08/2022

Actions
Related to Bug #13477: Captive Portal disconnecting a single user stops all traffic.ResolvedKristof Provost

Actions
Actions

Also available in: Atom PDF