Bug #2082
closedCaptive Portal error when client IPs are reused
100%
Description
This captive portal scenario appears to be broken (tested on 2.0.1):
- client_a has IP x.x.x.207, logs into CP, then leaves
- Before the CP idle timeout, somehow client_b gets IP x.x.x.207
- CP redirects client_b to the login page since the MAC doesn't match
- client_b attempts to login
- CP attempts to re-use the old session with a different MAC:
Jan 11 13:15:02 logportalauth[58810]: LOGIN: client_b, nn:nn:nn:b5:df:f0, x.x.x.207 Jan 11 13:15:02 logportalauth[58810]: CONCURRENT LOGIN - REUSING OLD SESSION: client_a, nn:nn:nn:32:5d:3e, x.x.x.207 Jan 11 13:14:30 php[58810]: /index.php: The command '/sbin/ipfw table 1 add x.x.x.207 mac nn:nn:nn:b5:df:f0 22464' returned exit code '71', the output was 'ipfw: setsockopt(IP_FW_TABLE_ADD): File exists'
- The user is still redirected back to the CP login since the MAC isn't in the table.
The user can't break out of this until they get a new IP or the old session times out on its own.
Updated by Chris Buechler almost 13 years ago
The log needs to be clarified so it detects IP reusage on a diff MAC rather than only checking the IP and thinking it's a concurrent login.
The DHCP lease length must be equal to or greater than the CP hard timeout.
Updated by Ermal Luçi almost 13 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 443abb317d52d57fba132eef7ebffa839538a0e4.
Updated by Ermal Luçi almost 13 years ago
Applied in changeset 843a6fe25ac303ceda46450a3f4ac24f69a54ecb.
Updated by Ermal Luçi almost 13 years ago
- Affected Version deleted (
2.0.x)
Changed error message. Probably should even warn user on dhcp timeout lower than CP timeout?
Updated by Ermal Luçi almost 13 years ago
Applied in changeset 2890cae51a424519662922e558bc939077b66c7c.
Updated by Ermal Luçi almost 13 years ago
Applied in changeset fbdc4b568453198fda514800286825fa9e74896f.
Updated by Jim Pingle almost 13 years ago
A non-fatal warning there would be nice. I'm not sure we should prevent it outright but they should be aware that it can cause problems.
Updated by Jim Pingle over 12 years ago
- Status changed from Feedback to Resolved
Updated by Luigi Capriotti about 11 years ago
The issue is not resolved, linking the DHCP lease time and CP timeouts is a workaround.
The CP must work based on MAC addresses given its uniqueness.
Updated by Chris Buechler about 11 years ago
it is a requirement to configure your DHCP lease time and CP timeout appropriately, that's not a work around, it's the only valid config.