Regression #13488
closedAll Captive Portal users are given the same limiter pipe pair
100%
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
Updated by Steve Wheeler about 2 years ago
- Subject changed from Captive Portal: All bandwidth limited users are given the same dummynet pipe pair to Captive Portal: All users are given the same dummynet pipe pair
This actually affects all users with or without bandwidth limiting set. When there is no limit set all user are passed through an unlimited pipe but that still gets removed when one user is disconnected.
This seems like a hangover from ipfw where all traffic had to be passed through a pipe.
Updated by jeroen van breedam about 2 years ago
any clue when a patch for 22.05 will be available ?
Updated by Kristof Provost about 2 years ago
Potential fix in https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/936
Updated by Steve Wheeler about 2 years ago
For reference the thread this was discussed and diagnosed in is here:
https://forum.netgate.com/topic/174489/22-05-cp-clients-have-connectivity-issues-after-x-amount-of-time
A fix was suggested and tested here:
https://forum.netgate.com/post/1068518
Updated by Reid Linnemann about 2 years ago
The changes in https://redmine.pfsense.org/projects/pfsense/repository/1/revisions/32661caf9549d8675763e814c9ceb9c2b47b2f02 which added the $check_only flag appear to have intended to prevent the check for available pipes from actually allocating them before user auth had completed, but the $pipeno returned from that call is still being passed to portal_allow(). The failed authentication case also still calls captiveportal_free_dn_ruleno(). I think the correct course of action here is to pass NULL for $pipe to portal_allow() and remove the call to captiveportal_free_dn_ruleno() in the failed auth case. In this way, a login attempt creates no pipes until after the user is authenticated, which I believe is the intention from the original changeset.
Updated by Kristof Provost about 2 years ago
Steve Wheeler wrote in #note-4:
For reference the thread this was discussed and diagnosed in is here:
https://forum.netgate.com/topic/174489/22-05-cp-clients-have-connectivity-issues-after-x-amount-of-timeA fix was suggested and tested here:
https://forum.netgate.com/post/1068518
The proposed fix there is essentially the same as my first attempt at a fix. It handles most cases and would certainly improve users' experience, but it's not fully correct. Reid figured out what the original patch was trying to do, and has suggested a better fix, which is what's now in the merge request.
Updated by Kristof Provost about 2 years ago
- Status changed from New to Ready To Test
Merged to pfSense CE and plus.
Updated by Marcos M about 2 years ago
- Project changed from pfSense Plus to pfSense
- Category changed from Captive Portal to Captive Portal
- Status changed from Ready To Test to Feedback
- Target version changed from 23.01 to 2.7.0
- Affected Plus Version deleted (
22.05) - Plus Target Version set to 23.01
Updated by Marcos M about 2 years ago
- Related to Bug #13475: Captive Portal per-user limiters malfunction added
- Related to Bug #13477: Captive Portal disconnecting a single user stops all traffic. added
Updated by Lev Prokofev almost 2 years ago
Looks like pipes per user fixed. Users using their own pipe.
Tested
23.01-DEVELOPMENT (amd64)
built on Fri Dec 02 06:04:48 UTC 2022
FreeBSD 14.0-CURRENT
3 users speeds 3Mbit Download 10Mbit Upload
02002: 10.280 Mbit/s 0 ms burst 0
q133074 100 sl. 0 flows (1 buckets) sched 67538 weight 0 lmax 0 pri 0 droptail
sched 67538 type FIFO flags 0x0 16 buckets 0 active
02003: 3.072 Mbit/s 0 ms burst 0
q133075 100 sl. 0 flows (1 buckets) sched 67539 weight 0 lmax 0 pri 0 droptail
sched 67539 type FIFO flags 0x0 16 buckets 0 active
02000: 10.280 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 1 active
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 ip 0.0.0.0/0 0.0.0.0/0 3 351 0 0 0
02001: 3.072 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
02004: 10.280 Mbit/s 0 ms burst 0
q133076 100 sl. 0 flows (1 buckets) sched 67540 weight 0 lmax 0 pri 0 droptail
sched 67540 type FIFO flags 0x0 16 buckets 1 active
0 ip 0.0.0.0/0 0.0.0.0/0 20 1846 0 0 0
02005: 3.072 Mbit/s 0 ms burst 0
q133077 100 sl. 0 flows (1 buckets) sched 67541 weight 0 lmax 0 pri 0 droptail
sched 67541 type FIFO flags 0x0 16 buckets 1 active
0 ip 0.0.0.0/0 0.0.0.0/0 14417 19261353 76 99069 3365
Updated by Jim Pingle almost 2 years ago
- Status changed from Feedback to Resolved
- Assignee set to Kristof Provost
- % Done changed from 0 to 100
Updated by Jim Pingle almost 2 years ago
- Subject changed from Captive Portal: All users are given the same dummynet pipe pair to All Captive Portal users are given the same limiter pipe pair
Updating subject for release notes.
Updated by Marcos M almost 2 years ago
- Related to deleted (Bug #13477: Captive Portal disconnecting a single user stops all traffic.)
Updated by Marcos M almost 2 years ago
- Has duplicate Bug #13477: Captive Portal disconnecting a single user stops all traffic. added
Updated by Marcos M almost 2 years ago
- Has duplicate deleted (Bug #13477: Captive Portal disconnecting a single user stops all traffic.)
Updated by Marcos M almost 2 years ago
- Related to Bug #13477: Captive Portal disconnecting a single user stops all traffic. added