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 #1

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.

Actions #2

Updated by jeroen van breedam about 2 years ago

any clue when a patch for 22.05 will be available ?

Actions #4

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

Actions #5

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.

Actions #6

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-time

A 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.

Actions #7

Updated by Kristof Provost about 2 years ago

  • Status changed from New to Ready To Test

Merged to pfSense CE and plus.

Actions #8

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
Actions #9

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
Actions #10

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

Actions #11

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
Actions #12

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.

Actions #13

Updated by Marcos M almost 2 years ago

  • Related to deleted (Bug #13477: Captive Portal disconnecting a single user stops all traffic.)
Actions #14

Updated by Marcos M almost 2 years ago

  • Has duplicate Bug #13477: Captive Portal disconnecting a single user stops all traffic. added
Actions #15

Updated by Marcos M almost 2 years ago

  • Has duplicate deleted (Bug #13477: Captive Portal disconnecting a single user stops all traffic.)
Actions #16

Updated by Marcos M almost 2 years ago

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

Also available in: Atom PDF