• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Captive Portal per User Bandwidth limits from RADIUS ignored

Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
12 Posts 2 Posters 9.5k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C
    communig8
    last edited by Apr 21, 2011, 12:15 PM

    Hi, Sorry if I've missed some stuff in this posting but this my first here so please be kind :-)

    I am testing pfSense 2.0 to replace a Captive Portal configuration based on DD-WRT Chilli-Spot that will be used in a number of locations.
    The current Captive Portal (Chilli-Spot) is working with RADIUS authentication and uses the WISPr bandwidth control attributes.
    So obviously I have configured pfSense to using RADIUS authentication and per user bandwidth.

    I have found that the bandwidth control values provided by RADIUS seem to be ignored and that speed tested connections going through
    pfSense run at the full speed of the connected network. In order to test that the rest of the configuration was ok for per user bandwidth limits
    I have tested with Captive Portal authentication set to Local and none. In both cases the default band width configured on the Captive Portal
    page is honoured on a speed test. I have run a network trace to verify that the correct WISPr vendor ID and attributes are in use.

    Have I missed something?
    Thanks for your help.

    Using pfSense 2.0-RC1 (i386) built on Tue Apr 19 23:03:17 EDT 2011

    Signatures are a sign of having signatures.

    1 Reply Last reply Reply Quote 0
    • E
      eri--
      last edited by Apr 21, 2011, 5:02 PM

      Show your CP configuration since that is important and also if possible a packet trace from the response of the radius with the WISPr attributes in it.

      1 Reply Last reply Reply Quote 0
      • C
        communig8
        last edited by Apr 21, 2011, 6:04 PM

        I dont have access to the trace data until next Tuesday.
        However, it is the same RADIUS server that was used with the Chilli-spot config which is currently working.
        The RADIUS server is hosted at WiFiGator.com
        The Vendor ID was the WISPr ID (14122)
        WISPr-Bandwidth-Max-Up was set to 1024000 (defined as 1000 k dn on WiFiGator.com)
        WISPr-Bandwidth-Max-Down was set to 102400 (defined 100 k up on WiFiGator.com)
        I will try to post a copy of the CP Config here too.

        Signatures are a sign of having signatures.

        1 Reply Last reply Reply Quote 0
        • C
          communig8
          last edited by Apr 21, 2011, 6:13 PM

          I have the config as a PDF which the forum will not let me attach, I have saved the pages as JPGs but the forum says they are too big.
          I can e-mail it to you.
          The config option are set as follows (if you are willing to trust me);
          RADIUS secrets removed!

          Services, Captive Portal
          Enable - check
          Interface - LAN
          Idle timeout 15
          Hard timeout blank
          After auth redir URL http://communityuk.net
          Disable concurrent logins - checked
          Disable MAC filtering - checked
          Enable per-user bandwidth restrictions - checked
          Download 2048, Upload 512
          RADIUS auth - checked
          Primary IP - 67.139.73.199
          secret - xxxxxxxxx
          Secondary IP - 67.139.73.199
          secret - xxxxxxxxx
          Send RADIUS accounting packets - checked
          Reauth connected users every minute - checked
          Accounting updates - Interim updates
          RADIUS NAS IP - WAN
          Use RADIUS Session-Timeout attribute - checked
          Save

          Signatures are a sign of having signatures.

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by Apr 21, 2011, 7:03 PM

            pfSense recognizes these attributes from WISPr
            WISPr-Bandwidth-Min-Up
            WISPr-Bandwidth-Min-Down
            WISPr-Bandwidth-Max-Up
            WISPr-Bandwidth-Max-Down

            otherwise it seems correct

            1 Reply Last reply Reply Quote 0
            • C
              communig8
              last edited by Apr 21, 2011, 7:05 PM

              So do we have a bug here?

              Signatures are a sign of having signatures.

              1 Reply Last reply Reply Quote 0
              • E
                eri--
                last edited by Apr 21, 2011, 8:20 PM

                Without a packet trace i cannot tell.
                Also an 'ipfw show' and 'ipfw pipe show' output might help.
                also a 'ipfw table all list' output.

                1 Reply Last reply Reply Quote 0
                • C
                  communig8
                  last edited by Apr 21, 2011, 8:35 PM

                  As I mentioned before, the trace shows;
                  The Vendor ID was the WISPr ID (14122)
                  WISPr-Bandwidth-Max-Up was set to 1024000 (defined as 1000 k dn on WiFiGator.com)
                  WISPr-Bandwidth-Max-Down was set to 102400 (defined 100 k up on WiFiGator.com)
                  But I understand why would will not take this as true without an actual trace.
                  Its Easter weekend in the UK but I can try to get the hardware together t run a test and get a trace.
                  Apart from the 'ipfw' commands, is the anything else that will help?
                  Seeing as I've got to get the hardware together for the trace I'd like to cover off anything else that will track it down.
                  Could you point me at where the code is that handles the dynamic pipe creation so I can read it through.

                  Signatures are a sign of having signatures.

                  1 Reply Last reply Reply Quote 0
                  • E
                    eri--
                    last edited by Apr 21, 2011, 9:28 PM

                    
                    1024000
                    
                    

                    Heh that is your issue.
                    pfSense by default assumes Kbit/s so you have to scale that value to take this into consideration.
                    Meaning you have to divide that value by 1024 or 1000 depending on preference.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eri--
                      last edited by Apr 21, 2011, 9:40 PM

                      I just committed this https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/2d4003aab1d969ed9ba3e52f2fe3ec083e4bef8c fix.
                      You wait for it in the next snapshot or apply manually.
                      It should fix your issues.

                      Thank you for the information.

                      1 Reply Last reply Reply Quote 0
                      • C
                        communig8
                        last edited by Apr 21, 2011, 9:46 PM

                        Ah so it was a bug!

                        Signatures are a sign of having signatures.

                        1 Reply Last reply Reply Quote 0
                        • C
                          communig8
                          last edited by Apr 23, 2011, 3:52 PM

                          I was so impressed by the speed of the fix, even if you were a bit odd about my offer to help, that
                          I got together all the hardware I would need to test, and it works!
                          Thanks for that. I'd like to see CheckPoint or Cisco move that fast!
                          Richard

                          Signatures are a sign of having signatures.

                          1 Reply Last reply Reply Quote 0
                          12 out of 12
                          • First post
                            12/12
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                            This community forum collects and processes your personal information.
                            consent.not_received