Captive Portal Bandwidth settings issue after 2.1.2 update?



  • I noticed the other day my internet at home seemed a little slow. finally had my hands free to look at it today, and did a speedtest to find I was getting 5/.5mbps rather than 175/10, so extremely slow. between my pfsense being installed in a vmware vm, and the update I did last week I wasn't quite sure where to look once I ruled out the usual modem and service issues. I couldn't find anything in the logs to indicate a problem. Just in case I did a factory reset and reimported my config.

    Just now while mucking about, I thought to look at the captive portal settings and noticed there was bandwidth caps for "logged in users". "Per-user bandwidth restriction" the option is labelled on the main captive portal settings page. Now most of my systems that need access to the internet are setup in the Pass-Through MAC options and previously they've always been able to access the internet at full speed.

    So now my question is, is there an issue in the latest update in which the MAC exclusions are being omitted incorrectly from the bandwidth settings? because once I turned off the captive portal my internet was full speed again, I've since re-enabled it and set the bandwidth to unlimited and it's still working fine.

    edit//
    I did a little research, and found this bug in the tracker that says it's fixed in 2.1.1
    https://redmine.pfsense.org/projects/pfsense/repository/revisions/7519cc29aedd0f957b4b124b2b1cf49e16938e2b

    I can read that bug description 3-4 different ways though, the forum topic makes more sense. From what I'm reading, I take it that it was broken before (the way I was accustomed to), and now it's fixed


  • Banned

    So what is your problem?

    You had BW restrictions applied and the speed was restricted? - This behaves exactly as it should.
    You then disabled the CP and the BW limit got removed?  - This behaves exactly as it should.
    You later on re-enabled the CP without BW limit set and got full speed?  - This yet again behaves exactly as it should.

    What's being "omitted incorrectly" where? Default up/down limit is being applied to MAC passthru entires unless you set up specific restrictions for each of those entries.



  • @doktornotor:

    What's being "omitted incorrectly" where? Default up/down limit is being applied to MAC passthru entires unless you set up specific restrictions for each of those entries.

    That's what I was trying to clarify. My understanding was that the default restrictions were applied to "logged in users", where pass through mac does not require a log on, which left me under the impression that systems with MAC pass-through were excluded from the restrictions.

    When you look at the description below the default bandwidth settings, it states "If this option is set, the captive portal will restrict each user who logs in to the specified default bandwidth"

    Clearly, I misunderstood, but from looking at the bug I linked in my first post, it appears the behavior I saw before was related to a bug with the bandwidth restrictions, so when I updated, and the bug was fixed in the update, I was experiencing the behavior as it was apparently intended, which was different than what I understood and had configured previously. I just wasn't 100% clear on how it was supposed to work, but I have my answer



  • I've been using pfSense since 1.2.3, four years ago. I picked it because of the Captive Portal and its passthrough MAC feature. I want to restrict bandwidth to computers that I haven't approved.

    It worked superbly for the past four years up till version 2.1. I just updated to 2.1.3 and found that the passthrough feature has now changed. Devices in the passthrough mac tab are also bandwidth-limited.

    Is this really the intended behaviour?

    The help page describes "Pass-Through MAC Tab" as:
    "Allows you to manage a list of MAC addresses which are allowed to bypass the portal."

    Now, wouldn't that mean the mac addresses which are listed in that tab will totally bypass the portal, including any bandwidth limits?

    That's how it has worked for the past four years. How come it has changed suddenly?

    Thanks.


  • Banned

    1/ Yes, it is clearly the intended behaviour when you read the source code; otherwise, the default BW limits would be totally useless (see below).

    2/ As for what changed when, it is even linked in the very first post:

    3/ If you dislike the wording of whatever help there, file a bug.



    1. I'm not a programmer, so I have to go by the documentation. The default BW limits have not been totally useless. Because:

    2. I read that post before but it didn't make sense to me. Have you used the bandwidth limiting feature on the captive portal before 2.1.1?

    Shudnawz says the bandwidth limiter on the main setup page doesn't do anything unless the host is authorized. I presume by "authorized host" he means hosts that have been added to the passthrough MAC or allowed IP/hostname lists, since users that are otherwise unauthorised will not have internet access.

    That is not what I have experienced since 1.2.3 though. The bandwidth limiter on the main setup page absolutely limits the speed for users that have logged in to the captive portal, just as its description says: "If this option is set, the captive portal will restrict each user who logs in to the specified default bandwidth."

    So - if a user logs in to the captive portal, they will be restricted to the specified default bandwidth.

    If a user does not log in (because they're on the passthrough MAC list), their speed does not get restricted, as long as no bandwidth limit is set on the passthrough or allowed list of course.

    I also came across this post by cmb in 2011. I figured an admin would be an accurate source for how things work.
    https://forum.pfsense.org/index.php?topic=38069.msg196731#msg196731

    He describes the way it used to work, i.e. a computer that's listed in the Allowed IP or MAC passthrough lists (with no individual bandwidth limit set) will not be subject to any bandwidth limits.

    Now, the bandwidth limit is applied to clients who log in as well as those entries in the allowed/mac lists, even though the entries don't have a bandwidth limit set.

    1. Which came first - the description or the source code? Is the bug in the description, or the updated source code?

    Thinking about it, perhaps I should lodge a feature request to allow selecting between pre-bugfix behaviour and post-bugfix behaviour rather than requesting for the description to be changed, since the pre-bugfix method has been around for so many years and some people have evidently relied on that behaviour.

    Thanks.


  • Banned

    Pre-bugfix behaviour made exactly zero sense. When you add something to MAC/IP passthrough, configure the BW limits accordingly. Instead of requiring people to configure everything else because the default limit will NOT apply otherwise at all. (IOW, the default limits did NOTHING.) Default means "it will apply to everyone unless explicitly configured otherwise". Not "it will not apply at all."



  • @doktornotor:

    Pre-bugfix behaviour made exactly zero sense.

    As with most things, "zero sense" depends on how it is being used.

    When you add something to MAC/IP passthrough, configure the BW limits accordingly.

    Yes, that's how it will have to be done now. That said, entering in 0 does not disable it like you'd think it should - the field just gets cleared after saving. I presume entering 9999999 would. I hope it doesn't increase resource use or add latency though.

    Instead of requiring people to configure everything else because the default limit will NOT apply otherwise at all.

    After at least 4 years of the original behaviour, everyone who has set it up the old way will now be required to reconfigure every single entry on their mac passthrough list one-by-one.

    (IOW, the default limits did NOTHING.) Default means "it will apply to everyone unless explicitly configured otherwise". Not "it will not apply at all."

    So which came first - the description, or the bug in the code? Because the description doesn't seem to match what you're saying.

    I quote the description again:
    "If this option is set, the captive portal will restrict each user who logs in to the specified default bandwidth. RADIUS can override the default settings. Leave empty or set to 0 for no limit."

    IOW, each user who logs in will be restricted to the specified default bandwidth. Therefore, users who don't have to log in will not be restricted. Otherwise I would expect it to say "If this option is set, the captive portal will restrict everyone to the specified default bandwidth."

    It also says to leave it empty or set to 0 for no limit.

    In the mac passthrough screen you can explicitly specify the bandwidth for each entry. It is empty by default, so that user should have no limit. However now, after the bugfix, the bandwidth field is empty but that client is still subject to the limit on the main config screen. And as I mentioned earlier, leaving it empty or setting it to 0 does not result in no limit.


  • Banned

    Sigh, this debate goes clearly nowhere. Which came first is irrelevant and does not make failure to apply default values and rendering the defaults limits feature completely useless any less of a bug. Neither does "oh it's been broken for 4 years".

    As said, if you absolutely cannot live with the description, it can be changed.

    However now, after the bugfix, the bandwidth field is empty but that client is still subject to the limit

    Yeah, see, that's what the "default" means as I already explained multiple times. If you desire different limits applied to some explicitly configured clients, you can configure them explicitly. Configure nothing means the default applies. Pretty damn obvious.

    If this is undesired, why are you configuring the default values at all if you do not want them?  ::)



  • My point was that pre-bugfix, the limiting worked just as the descriptions describe it.

    Post-bugfix, it doesn't.

    So I was curious as to whether or not the change was truly intentional, since the feature now no longer seems to match the description.


  • Banned

    Pre-bugfix, the default limiting did NOT work at all. Those were totally useless configuration fields not honored at all.



  • @doktornotor:

    Pre-bugfix, the default limiting did NOT work at all. Those were totally useless configuration fields not honored at all.

    As I mentioned earlier, that is incorrect. Pre-bugfix, the default limiting applied to ALL clients who log in to the portal. If you did a search on the forum you'd find people using it. Otherwise it wouldn't have gone unnoticed for so long.

    The limits did not apply to clients on the mac bypass list. That behaviour matches the description of the feature, as I understand it. But now it doesn't.


  • Banned

    No, that thing did not work with "Pass-through MAC Auto Entry" either, at least.

    Let me state again that a default value should always apply - unless you explicitly configured other values for other cases. It does NOT mean it should

    • be ignored in half of cases
    • be ignored in most of cases
    • be ignored in random cases not thought of before
    • apply only when a random user finds it convenient to apply, based on guessing/crystall ball/…

    Any of the above is just completely unintuitive design causing confusion and more bugs.

    That behaviour matches the description of the feature, as I understand it. But now it doesn't.

    Great. So, how about

    • fixing the description so that it does not describe buggy behaviour that's no longer in place
    • NOT configuring default limits in situations when it's clearly undesired?

    Would sound like a problem solved, no?  ::)



  • @doktornotor:

    No, that thing did not work with "Pass-through MAC Auto Entry" either, at least.

    Are we talking about the same thing? I'm referring to the "Per-user bandwidth restriction" in the Captive Portal configuration screen.
    It absolutely, definitely worked exactly as the description describes it.

    i.e.

    On pfSense 1.2.3 till 2.1:

    I set a bandwidth limit of 256/64k.
    A user logs in to the captive portal.
    Their download and upload speed is capped at 256/64k.
    A device that has its MAC address in the bypass list with 0 or no entry in the bandwidth limit field can access the internet at full speed.

    That absolutely worked, 100%.

    Let me state again that a default value should always apply - unless you explicitly configured other values for other cases. It does NOT mean it should

    • be ignored in half of cases
    • be ignored in most of cases
    • be ignored in random cases not thought of before
    • apply only when a random user finds it convenient to apply, based on guessing/crystall ball/…

    Any of the above is just completely unintuitive design causing confusion and more bugs.

    The description very clearly states when it applies - to logged-in users. No confusion there.

    Post-bugfix however, there's now confusion as to how to assign no limits to an entry in the mac bypass list. Setting the bandwidth values to 0 or empty does not result in no limits, as the instructions on the main config page describes.

    Great. So, how about

    • fixing the description so that it does not describe buggy behaviour that's no longer in place
    • NOT configuring default limits in situations when it's clearly undesired?

    Would sound like a problem solved, no?  ::)

    Sure, the description can be changed.

    But what was the original intended behaviour? To me, it looks like it was working just as it was intended to. Now, the bugfix resulted in behaviour that does not match the original description. Was it changed by mistake?

    Obviously I can tell you prefer the new behaviour that doesn't seem to match the original description, but it does look like you don't even use the captive portal yourself - otherwise you would have mentioned it or flagged it years ago, no?

    I'm not the only person who raised this question and I'm sure there are others who don't post here who might be facing the same situation, so I just wanted to find out if the change was intentional, not whether or not you prefer the new behaviour.

    Thanks for the replies though.



  • Yeah the behaviour has been that way but even until 2.1 there was no bw limits you could apply to such hosts.
    The behaviour has been changed to match the configuration since an allowed host is still a user.

    What you can do is specify 0 when you configure such hosts or the required bw.
    This is mostly to be consistent all over with the limits.



  • @ermal:

    Yeah the behaviour has been that way but even until 2.1 there was no bw limits you could apply to such hosts.

    Hmm, which hosts are you referring to? The ones in the mac passthrough list? The bw limits definitely worked for all users who logged in through the captive portal.

    The behaviour has been changed to match the configuration since an allowed host is still a user.
    What you can do is specify 0 when you configure such hosts or the required bw.
    This is mostly to be consistent all over with the limits.

    That doesn't seem to be working for me - 0 isn't accepted. When I change an existing entry in the MAC passthrough list to have 0 as both the upload and download values, when I click on Save and open that entry again, the values are blank. If I set a number other than 0, it is saved.

    All the entries on my mac list have the up and down bandwidth blank. Following the description on the main config page, setting it to 0 or blank means that host will have no limit. However, the hosts are still limited.

    Thanks!


Log in to reply