Captive Portal Login Loop
-
I can confirm that my DHCP lease times are not correct. I will apply and post results within a day or so once I see some heavy usage. Share away on the forums any info you need I can provide.
-
Ok, that may be the only issue here then. That log message is probably misleading in this case, it's the fact it's a reassigned IP that causes issues because the IP to MAC association is no longer the same.
We'll consider some alternatives to clarify that scenario. Maybe not just checking IP there, but checking IP and MAC and logging a more appropriate message if there is a problem because the hard timeout is longer than the DHCP lease. Open to other ideas if anyone has suggestions, we'll also discuss in more detail internally. Need something other than input validation/warnings in CP in comparison to the DHCP lease times since some installs do DHCP elsewhere.
-
your DHCP lease time should be equal or higher than your hard timeout, to ensure no one is reassigned an IP that's allowed through captive portal.
How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?)
AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.
-
your DHCP lease time should be equal or higher than your hard timeout, to ensure no one is reassigned an IP that's allowed through captive portal.
How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?)
AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.
It is independent if you use vouchers or username/password. The HardTimeout works always the same way. But if you are logged into CP with IP: 1.2.3.4 and MAC: 11:22:33:44:55:66 (IP from DHCP with lease 12h) then it is probably possible that you get an different IP (2.3.4.5) from DHCP after 12h and then it conflicts with the login on the CP because the first login was with MAC: 11:22:33:44:55:66 IP: 1.2.3.4 and the second with with MAC: 11:22:33:44:55:66 IP: 2.3.4.5 but the HardTimeout didn't expire.
The voucher time of 2 days is the totaly expiration time.
In short: DHCP lease must be longer than hard timeout.
-
AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.
But if you are logged into CP with IP: 1.2.3.4 and MAC: 11:22:33:44:55:66 (IP from DHCP with lease 12h) then it is probably possible that you get an different IP (2.3.4.5) from DHCP after 12h and then it conflicts with the login on the CP because the first login was with MAC: 11:22:33:44:55:66 IP: 1.2.3.4 and the second with with MAC: 11:22:33:44:55:66 IP: 2.3.4.5 but the HardTimeout didn't expire.
The voucher time of 2 days is the totaly expiration time.
In short: DHCP lease must be longer than hard timeout.
Supposing you have configured your CP with a 6hr DHCP lease and 2 day HardTimeout, in your example wouldn't dhcpd simply check the dhcpd.leases file and re-assign that client the same IP 1.2.3.4 (as long as his MAC stays the same 11:22:33:44:55:66)? Also, iirc a client will start trying to renew its lease at 50% of the lease time, so for a 6hr lease time it'd start trying to renew its lease at about 3hrs.
It seems to me that these issues are much more likely to arise if the DHCP address pool is relatively small compared with the client population.
-
The chance that there will be a problem is higher if the DHCP address pool is small - you are correct.
Perhaps the thread starter should think about the (high) hard Timeout. I do not think there are people in a hotel which are online 48hours without getting to sleep or something else.
Further the hard timeout could be a possibility to protect against people which are using a continous high bandwidth. The Hardtimeout interrups this usage (downloading a large .iso file over night).
I would think about a hard timeout of 6hrs. -
Perhaps the thread starter should think about the (high) hard Timeout. I do not think there are people in a hotel which are online 48hours without getting to sleep or something else.
I think his 24hr hard timeout is reasonable, since he probably doesn't want to force his hotel guests to re-login every few hours.
I'm still unclear about the nature of the problems arising from dhcp lease time < HardTimeout, but I guess I'll have to check the code.
Further the hard timeout could be a possibility to protect against people which are using a continous high bandwidth. The Hardtimeout interrups this usage (downloading a large .iso file over night).
I would think about a hard timeout of 6hrs.Most big downloads are done with P2P … and limiting P2P traffic is quite difficult.
Another option would be data transfer quotas, but pfsense's CP doesn't support it afaik. -
I checked my lease times, they are set to default which it says is 7200s for lease time and 86400s for max lease time. Isn't this already the way it should be?
As said above, I choose 24hrs timeout because it is annoying to have to click I agree again. But if this is the problem i will gladly adjust it.
-
The chance that there will be a problem is higher if the DHCP address pool is small.
I checked this setting and this may have been my problem, only time will tell.
My address pool was set to 150 ips which is obviously too small for the hotel. I changed it to lease 10.58.185.100-10.58.187.250.
It makes sense to me that this could be a ip pool related problem since in a couple of instances doing ipconfig / release and /renew fixed it. However we have had a couple that this did not work with but these seem to be in the evening when all the guests are in house. The fix for these guests has been to reset the captive portal thus emptying the lease table. So maybe ipconfig /release /renew couldn't work because there wasn't enough ips available in the evening?
We shall see.
-
Although I had a big DHCP pool it was not really that large. I did notice in my logs DHCP server complain of no free IPs. So I made a very large subnet and I will post feedback. I think agreessive DHCP pools + captive portal = bad
-
Perhaps it would make sense to adjust min and max lease times:
min 7200
max 14400 -
According to the settings page for dhcp lease times are in seconds. Hence 86400 = 1440min. So I already have that setting in there.
Thanks for the suggestion though.
-
So far so good!
I wanted to post a little something I am noticing on my system, So far tonight we have not had any issues reported, and for the last 2 nights it has broken by this time- So I am hopeful that the issue is resolved-Wait and see on that one though.
What I have noticed tonight is that the only 3 times I have seen the "CONCURRENT LOGIN" message in the logs has been on iPhone devices- coincidence or not?? Who knows…
Also since increasing the size of the DHCP pool the only addresses being assigned are the new ones not the old ones with the exception of one of the iPhones that generated the CONCURRENT LOGIN message...Maybe thats the way its supposed to work- Just thought I would point that out. On my DHCP leases page if I show all leases there are a ton of expired leases from days ago, Should these be showing up?
At this point I am wondering whats going to happen when it reaches the end of my new IP Pool.
-
Also since increasing the size of the DHCP pool the only addresses being assigned are the new ones not the old ones with the exception of one of the iPhones that generated the CONCURRENT LOGIN message…Maybe thats the way its supposed to work- Just thought I would point that out. On my DHCP leases page if I show all leases there are a ton of expired leases from days ago, Should these be showing up?
At this point I am wondering whats going to happen when it reaches the end of my new IP Pool.
Expired leases will hang around in the leases file for a while (exact details on that I don't recall, but the dhcpd.leases man page for ISC dhcpd explains that IIRC if you're interested in details). Those IPs are available for assignment to a new device if/when needed.
The phone you noted is just renewing its existing IP from the sounds of it. Everything else from your description was offline long enough that their lease expired, and they got the next available from the larger pool.
-
How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?)
AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.
That's not specific to using vouchers, or RADIUS, or no authentication, just make sure your DHCP lease lifetime is equal to or greater than your CP hard timeout in all cases.
Clients will be re-assigned the same IP in most cases, but commonly not in environments like larger hotels where lots of devices come and go and you have a relatively small DHCP pool for the number of devices, so it has to reassign IPs whose leases have recently expired.