Project

General

Profile

Bug #2082

Captive Portal error when client IPs are reused

Added by Jim Pingle about 9 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
2.1
Start date:
01/11/2012
Due date:
% Done:

100%

Estimated time:
Affected Version:
Affected Architecture:
Release Notes:
Default

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.

Associated revisions

Revision 843a6fe2 (diff)
Added by Ermal Luçi about 9 years ago

Fixes #2082. Correct checking of existing session to take into consideration when possible/needed the mac address

Revision 443abb31 (diff)
Added by Ermal Luçi about 9 years ago

Fixes #2082. Correct checking of existing session to take into consideration when possible/needed the mac address

Revision fbdc4b56 (diff)
Added by Ermal Luçi about 9 years ago

Fixes #2082. Actually just correct the log to display the correct information

Revision 2890cae5 (diff)
Added by Ermal Luçi about 9 years ago

Fixes #2082. Actually just correct the log to display the correct information

History

#1 Updated by Chris Buechler about 9 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.

#2 Updated by Ermal Luçi about 9 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#3 Updated by Ermal Luçi about 9 years ago

#4 Updated by Ermal Luçi about 9 years ago

  • Affected Version deleted (2.0.x)

Changed error message. Probably should even warn user on dhcp timeout lower than CP timeout?

#5 Updated by Ermal Luçi about 9 years ago

#6 Updated by Ermal Luçi about 9 years ago

#7 Updated by Jim Pingle about 9 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.

#8 Updated by Jim Pingle over 8 years ago

  • Status changed from Feedback to Resolved

#9 Updated by Luigi Capriotti over 7 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.

#10 Updated by Chris Buechler over 7 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.

Also available in: Atom PDF