Actions
Bug #2082
closedCaptive Portal error when client IPs are reused
Start date:
01/11/2012
Due date:
% Done:
100%
Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:
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.
Actions