Project

General

Profile

Actions
Copy link

Bug #2082

closed
JP

Captive Portal error when client IPs are reused

Bug #2082: Captive Portal error when client IPs are reused

Added by Jim Pingle over 14 years ago. Updated almost 13 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.

CB Updated by Chris Buechler over 14 years ago Actions
Copy link
 #1

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.

EL Updated by Ermal Luçi over 14 years ago Actions
Copy link
 #2

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

Applied in changeset commit:443abb317d52d57fba132eef7ebffa839538a0e4.

EL Updated by Ermal Luçi over 14 years ago Actions
Copy link
 #3

Applied in changeset commit:843a6fe25ac303ceda46450a3f4ac24f69a54ecb.

EL Updated by Ermal Luçi over 14 years ago Actions
Copy link
 #4

  • Affected Version deleted (2.0.x)

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

EL Updated by Ermal Luçi over 14 years ago Actions
Copy link
 #5

Applied in changeset commit:2890cae51a424519662922e558bc939077b66c7c.

EL Updated by Ermal Luçi over 14 years ago Actions
Copy link
 #6

Applied in changeset commit:fbdc4b568453198fda514800286825fa9e74896f.

JP Updated by Jim Pingle over 14 years ago Actions
Copy link
 #7

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.

JP Updated by Jim Pingle about 14 years ago Actions
Copy link
 #8

  • Status changed from Feedback to Resolved

LC Updated by Luigi Capriotti almost 13 years ago Actions
Copy link
 #9

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.

CB Updated by Chris Buechler almost 13 years ago Actions
Copy link
 #10

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