0001132: Mac OS X DHCP issues after a VLAN change on wireless networks - PacketFence

PacketFence - BTS - PacketFence

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0001132

PacketFence

upstream

public

2010-12-01 12:05

2011-01-11 09:49

Reporter

obilodeau

Assigned To

obilodeau

Priority

normal

Severity

major

Reproducibility

random

Status

resolved

Resolution

no change required

Platform

OS Version

Product Version

Target Version

2.1.0

Fixed in Version

fixed in git revision

fixed in mtn revision

Summary

0001132: Mac OS X DHCP issues after a VLAN change on wireless networks

Description

Based on the setup we are sometimes able to reproduce the problem 100% of the time or not at all.

The issue: Mac OS X after a wireless deauthentication (desassociation) doesn't do a DHCP Discover.

What happens:
- we deauth the Mac OS X client
- Mac OS X client reconnects, get a different VLAN assigned
- it waits for its DHCP lease to expire
- it then does DHCP Request on the server where it obtained it's last IP
- a default DHCP server configuration will not reply to that DHCP Request thinking it's not for him (wrong IP information on wrong interface)
- after a couple of minutes the Mac OS X client abandon the DHCP Requests and do a DHCP Discover
- DHCP Server responds
- Mac OS X client has an IP in the right VLAN

Because of the lease expiry delays and the DHCP Request timeout delays, it takes several minutes to gain network access. This is unacceptable. On Windows, everything works fine.

Expected:
- we deauth the Mac OS X client
- Mac OS X client reconnects, get a different VLAN assigned
- Mac OS X issues a DHCP Discover (it's in a new network after all!)
- it gets an IP in the good VLAN

Workarounds:
We are working on workarounds which involves sending a DHCP NAK (non-acknowledge) if we see a DHCP Request coming with the wrong IPs on the wrong interface. This way we reduce the delay window only to the dhcp lease timeout. Here's the flow with the workaround:
- we deauth the Mac OS X client
- Mac OS X client reconnects, get a different VLAN assigned
- it waits for its DHCP lease to expire
- it then does DHCP Request on the server where it obtained it's last IP
- DHCP Server sends a DHCP NAK to the client
- Mac OS X client does a DHCP Discover
- DHCP Server responds
- Mac OS X client has an IP in the right VLAN

As stated earlier, some setups are affected some aren't so we aren't sure where the interaction changes. Here's a list of variables to look after:
- ip-helpers based or not (vs bridged layer2 to dhcp)
- DHCP Server based on Windows or Linux
- Using a Controller or fat Access Points

We are investigating on this but any findings would help us a lot!

Steps To Reproduce

Additional Information

workarounds:

- in bridged mode (no ip-helpers)
run a DHCP Server per interface with -pf (pid file) and -cf (different config) in that config put deny all on subnets you should never see on that VLAN

- in ip-helpers mode
we are still discussing this one (one ip-helper on eth0 doing the right thing or several)