Project

General

Profile

Actions
Copy link

Bug #2082

closed

Captive Portal error when client IPs are reused

Added by Jim Pingle over 12 years ago. Updated over 10 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:
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
Copy link
 #1

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

Actions
Copy link
 #2

Updated by Ermal Luçi about 12 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #3

Updated by Ermal Luçi about 12 years ago

Actions
Copy link
 #4

Updated by Ermal Luçi about 12 years ago

  • Affected Version deleted (2.0.x)

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

Actions
Copy link
 #5

Updated by Ermal Luçi about 12 years ago

Actions
Copy link
 #6

Updated by Ermal Luçi about 12 years ago

Actions
Copy link
 #7

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

Actions
Copy link
 #8

Updated by Jim Pingle almost 12 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #9

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

Actions
Copy link
 #10

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

Actions
Copy link

Also available in: Atom PDF