Captive Portal Bandwidth issue
-
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
I understand the issue with realtek but I have had issues with intel's also, so theres that.
I know, even Intel can fail. The contrat would surprise me. Had to mention these type of interfaces, as it's not uncommon to find out after days of debugging that it was a
USB NIC that only works well on paper.Understand, been doing this for a long time and I have seen plenty of interface card issues, I do not believe that to be the issue since the other interface that is trunked but not behind captive portal sees no issue. Im scratching my head since I just do not know what the issue is and where to look etc... :)
-
Remove all possible 'source of problems' : reserve a NIC for the the portal without any VLAN stuff.
-
@Gertjan said in Captive Portal Bandwidth issue:
Remove all possible 'source of problems' : reserve a NIC for the the portal without any VLAN stuff.
I wish I could but I do not have the luxury no more ports to be had EXCEPT for a realtek interface....I'd rather not do that...my current plan is to disable the captive portal on the interface and test and see what that does, if I get normal speeds then something in captive portal is bodged up or my configuration which is drop dead simple but thats my current plan.
-
Had someone on location that could do some testing, turning off captive portal returned the performance compared to the other interfaces so it's something going on with captive portal portion. Any suggestions on where to look?
-
@bishoptf
Not yet.
This afternoon (GMT) I'll hook up my PC directly to the captive portal interface without the limiting 100 Mbit switch.I should see :
as that's my LAN/WAN/whatever 'physical' limit.
Keep in mind that the captive portal is not 'some code' or special 'interface mode'.
It's just two or three 'pf' firewall rules, the same rules that are used on your LAN and other interfaces.
You can see them here : take a look at /tmp/rules.debug -
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf
Not yet.
This afternoon (GMT) I'll hook up my PC directly to the captive portal interface without the limiting 100 Mbit switch.I should see :
as that's my LAN/WAN/whatever 'physical' limit.
Keep in mind that the captive portal is not 'some code' or special 'interface mode'.
It's just two or three 'pf' firewall rules, the same rules that are used on your LAN and other interfaces.
You can see them here : take a look at /tmp/rules.debugYea, understand all I know is if I turn Captive portal OFF I get wire speeds or what I expect, if I turn Captive portal ON I get 30mbps or there abouts. I have nothing enabled from a bandwidth restriction. I've toggled the per user bandwidth on and off and even tried to set a number and still get the same speed. It's no longer working for me and not sure what or how its broke.
Thinking of backing up the portal configuration and restoring the captive portal configuration to a new zone since I am not sure what else to try.
-
I just checked the xml and counted how many MAC addresses I have and its 1367. Not sure if that is an issue but the other thing I notice is that when I make edit the captive portal and I go to save it takes forever to save etc. Contemplating just getting rid of Captive Portal altogether since all it does is displays terms and conditions.
-
@bishoptf said in Captive Portal Bandwidth issue:
I just checked the xml and counted how many MAC addresses I have and its 1367
??? And now you tell this ?
Check Diagnostics > Limiter Info page : you have 2x1367 pipes and 2x1367 schedulers ?
No need to check the xml config file manually, you can see them on the portal's "MACs" page.Yeah, that can/could explain the/a difference.
See one thread lower, see/click here, where I added 500 randomly generated MAC into the portal's "MACs" page.
That didn't make any difference - in speed - for me.Still, strange, a captive portal is by nature non-trusted network, and people have to do some work to join the portal = they have to login. And when they are thrown off, because of a time out for example, they have to login again. That's the price they have to pay for a free internet access.
Adding all those macs of these devices means you have a lot of devices that have access "all the time" on your portal so they are not really strangers or unknown people. Administrating them like this, on a portal, is a pain. -
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
I just checked the xml and counted how many MAC addresses I have and its 1367
??? And now you tell this ?
Check Diagnostics > Limiter Info page : you have 2x1367 pipes and 2x1367 schedulers ?
No need to check the xml config file manually, you can see them on the portal's "MACs" page.Yeah, that can/could explain the/a difference.
See one thread lower, here, where I added 500 randomly generated MAC into the portal's "MACs" page.
That did't make any difference for me.Still, strange. A captive portal is by non trusted network, and people have to do some work to join the portal = login.
Adding all those macs of these devices means you have a lot of devices that have access "all the time" on your portal so they are not really strangers or unknown people. Administrating them like this, on a portal, is a pain.Yeah its not really managing them, its a church and the click through is once for terms and conditions and then we record the mac address and from then on they are automatically authenticated. I was trying to avoid having them have to have a click through for each time they are connecting to hotspot. Trying to figure out how to do the terms and conditions another way, where its easy etc. I do not see a high CPU load but obviously its not working.
-
@bishoptf said in Captive Portal Bandwidth issue:
for terms and conditions and then we record the mac address and from then on they are automatically authenticated
.... and the next time they drop by, their device, as they all do these days, generates a new random MAC address ... which will get stored also in portal.
Steady but slowly your portal will be brought to its knees because the MAC list will grow, and grow ....It s a church, right ? people don't stay for hours, what about the plain and easy, and no hassle and no maintenance, classic login, maybe without a password, just an OK button.
-
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
for terms and conditions and then we record the mac address and from then on they are automatically authenticated
.... and the next time they drop by, their device, as they all do these days, generates a new random MAC address ... which will get stored also in portal.
Steady but slowly your portal will be brought to its knees because the MAC list will grow, and grow ....It s a church, right ? people don't stay for hours, what about the plain and easy, and no hassle and no maintenance, classic login, maybe without a password, just an OK button.
Not sure I understand why it should matter, why if I am not using limiters would it cause a performance issue. I think its a bug myself since I do not think just having mac addresses should be causing a performance issue. I do not have a password, the only difference is I record the mac address today so they only have to do it once. I know on my phone i've never been prompted again.
-
I connected my desktop PC to my main captive portal switch, this time it was 1 Gbit/sec switch.
I logged in, I'm using radius to login in, I guess that doesn't matter, there are no user or speed restrictions that I know of.
which is my ISP speed right now.
-
@Gertjan said in Captive Portal Bandwidth issue:
I connected my desktop PC to my main captive portal switch, this time it was 1 Gbit/sec switch.
I logged in, I'm using radius to login in, I guess that doesn't matter, there are no user or speed restrictions that I know of.
which is my ISP speed right now.
Understand that its working for you but I am not using radius and not sure if that changes the behavior but it's not wiorking for me, or reduced bandwidth/performance issues. I am going to recreate the zone etc and do more testing and see if I can figure it out...
-
@bishoptf said in Captive Portal Bandwidth issue:
Understand that its working for you but I am not using radius
I've switched to the default pfSense user manager mode, where I also have all the allowed users that can login on the portal.
Didn't make any difference. -
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
Understand that its working for you but I am not using radius
I've switched to the default pfSense user manager mode, where I also have all the allowed users that can login on the portal.
Didn't make any difference.I believe its the high number of approved mac addresses, I see other users having issues when modifying the cpzone with a high number of addresses and I see that also. I am going to remove most of the ones I have and see how that reacts. I know not having it on at all solves the issue, but maybe I will not add any mach address but just put an 24hr hard timeout and I assume those addresses will be cleaned up after the timeout expires, correct? Not sure what else to try, I have deleted the zone and added it back although with a different name and see the same issue. All I need is for the users to see the terms and conditions and then have access.
-
@bishoptf said in Captive Portal Bandwidth issue:
but just put an 24hr hard timeout and I assume those addresses will be cleaned up after the timeout expires, correct?
You use this option, right ? :
IMHO : don't do that, as MACs will get added, but nothing has been put in place to auto remove them. The MAC list will grow indefinitely, which obliges you to check upon this list regularly. Because no details are added like : "when the MAC" was added, you won't know what to delete, and what to leave in place.
IMHO (again) : this option should only be used when you know all the devices that use your portal. Awkward situation, because for these devices you wouldn't need a portal in the first place.
Btw : I've added 500 more random MAC addresses to my captive portal MAC list, now I have 1000 of them :
the portal didn't become any slower .....
-
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
but just put an 24hr hard timeout and I assume those addresses will be cleaned up after the timeout expires, correct?
You use this option, right ? :
IMHO : don't do that, as MACs will get added, but nothing has been put in place to auto remove them. The MAC list will grow indefinitely, which obliges you to check upon this list regularly. Because no details are added like : "when the MAC" was added, you won't know what to delete, and what to leave in place.
IMHO (again) : this option should only be used when you know all the devices that use your portal. Awkward situation, because for these devices you wouldn't need a portal in the first place.
Btw : I've added 500 more random MAC addresses to my captive portal MAC list, now I have 1000 of them :
the portal didn't become any slower .....
Yeah Again not sure what is different but mine is slow, going to remove most of the addresses and do some testing this morning and see how it performs. Every use case is different, this is for a church most of the same folks are there every week and the idea was this way they only add to go through the portal page once and then not have to bother with it. If I turn that off they will have to get the portal page open every time they are up there and re-directing doesn't always work that well. But not sure why I am seeing the performance issues but its pretty clear that I am, turn it off and it works, turn it on and performance is low.
-
@bishoptf said in Captive Portal Bandwidth issue:
will have to get the portal page open every time they are up
That's, afaik, ones a week, right ?
Hospital, Hotel, Mc Donalds or the local library : when you enter, you use their captive portal, and you to do some thing (filling out a forum on the screen, the login screen).
I'm using the (pfSense) captive portal for more the a decade in a hotel.
Works great.
It's very rare these days I have to assist some one with the connection.
Even the old / stupid and ignorant ones connects with the info we show in the room.True, there are still some devices that "can't connect". These are mostly the the very old devices, or their owners are way over the edge about security - the toc-tic educated ones, for example.
"they don't like unknown [wifi]network !".
Me : Ok..... then why do you want to use my hotel - for you unknown - network then ???
So, filling a form on a screen (they bought a smartphone, right ??) won't be that hard for them, they have seen worse.
And sorry, I have to say/ask it : going to a church and connecting your phone ?
The connection with the guy up there doesn't need any wifi as far as I know.
And have your phone going of during a burial is good enough to get yourself shot .... They've burned people (same church btw) for far less. -
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
will have to get the portal page open every time they are up
That's, afaik, ones a week, right ?
Hospital, Hotel, Mc Donalds or the local library : when you enter, you use their captive portal, and you to do some thing (filling out a forum on the screen, the login screen).
I'm using the (pfSense) captive portal for more the a decade in a hotel.
Works great.
It's very rare these days I have to assist some one with the connection.
Even the old / stupid and ignorant ones connects with the info we show in the room.True, there are still some devices that "can't connect". These are mostly the the very old devices, or their owners are way over the edge about security - the toc-tic educated ones, for example.
"they don't like unknown [wifi]network !".
Me : Ok..... then why do you want to use my hotel - for you unknown - network then ???
So, filling a form on a screen (they bought a smartphone, right ??) won't be that hard for them, they have seen worse.
And sorry, I have to say/ask it : going to a church and connecting your phone ?
The connection with the guy up there doesn't need any wifi as far as I know.
And have your phone going of during a burial is good enough to get yourself shot .... They've burned people (same church btw) for far less.More testing yesterday with the smaller list and as I expected it performed fine. I can only assume that maybe the combination of my hardware and the large number of mac addresses causes the issue. Going to try a 12 hour usage window and see how that works. I think most modern devices see that there is a sign in but some older devices even my linux laptop can be a pain getting the portal page to come up but will go with that for now. The other option is to just run an open network without the portal and no terms and conditions, lot of mixed opinions out there if its really needed but I'm not a lawyer so I will continue to try to use the portal and so I can display Terms and conditions.
-
@bishoptf said in Captive Portal Bandwidth issue:
some older devices even my linux laptop can be a pain
The concept of a captive portal is created and defined by pfSense or whatever router you use.
Most of the captive portal support is build into the OS of the device the user uses.
Our pfSense, and its captive portal, is nothing more as a firewall that block everything, except the DHCP protocol (UDP, ports 67 and 68) and DNS (port 53, UDP and TCP).
DHCP still works - has to work ! - on a portal, so the device will get the correct network info.
DNS has to work, because : on the visiting side, the device :
has to execute a "connection challenge" so check if, upon connecting to the wired or wireless network, a connection to the Internet is possible.
It does this with an OD based simple "http" (NOT https !) request.
For example, an iOS device will use this URL :http://captive.apple.com/hotspot-detect.html
Before this request can be made, first, as always, the domain name has to be reolved to an IP.
So, a DNS request is made to resolve "captive.apple.com".
When the IP comes back, a request is made to 17.253.109.202 on port 80 - and the requested file will be "hotspot-detect.html".On the pfSense, this request to 'somewhere' with destination port 80, protocol TCP, will get redirected to the Captive portal's web server, using some 800x port. result : The portal's login page comes back.
And that's not what the OS want .. it wants this answer back http://captive.apple.com/hotspot-detect.html (click on the link to se the answer).
So, now the OS launches a system's default browser, and repeats the request.
This time the end user can see the login page, and deal with it.This gets me to my point : a captive portal is not only a pfSense thing. You, as a portal admin can't deal with every situation created by every possible device - "it's not your problem".
These days, captive portals are real, and are proposed by many companies, or every other nut that wants to share his connection. So every known OS today has the build in portal support these days.
Using old software on modern network (Internet is not going to wait for you ...) is indeed a pain.
But, hey, that's live.
You keep the old stuff and deal with it, every day a bit more.
Or you get the new stuff and deal with it, every day a bit more.
