Bug #2082

Captive Portal error when client IPs are reused

Added by Jim P over 2 years ago. Updated 5 months ago.

Status:Resolved Start date:01/11/2012
Priority:Normal Due date:
Assignee:- % Done:

100%

Category:Captive Portal
Target version:2.1
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.

Associated revisions

Revision 843a6fe2
Added by Ermal Luçi about 2 years ago

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

Revision 443abb31
Added by Ermal Luçi about 2 years ago

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

Revision fbdc4b56
Added by Ermal Luçi about 2 years ago

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

Revision 2890cae5
Added by Ermal Luçi about 2 years ago

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

History

#1 Updated by Chris Buechler over 2 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 2 years ago

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

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

  • Affected version deleted (2.0.x)

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

#7 Updated by Jim P about 2 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 P almost 2 years ago

  • Status changed from Feedback to Resolved

#9 Updated by Luigi Capriotti 5 months 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 5 months 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