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

Bug Tracking System

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

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

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!

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)

Tags

No tags attached.

fixed in git revision

fixed in mtn revision

Attached Files

Relationships

related to

0001050

closed

obilodeau

Force DHCP to send DHCPNACKs to client that juste changed VLAN that insist on getting an invalid IP

Notes
(0001784) obilodeau (reporter) 2010-12-01 14:47	We tested and were no longer able to reproduce under Mac OS 10.6.5. It was probably fixed under "Improves reliability of Ethernet connections." according to http://support.apple.com/kb/HT4250 [^]

(0001802) obilodeau (reporter) 2011-01-11 09:49	Update your Mac OS X to 10.6.5.

Issue History
Date Modified	Username	Field	Change
2010-12-01 12:05	obilodeau	New Issue
2010-12-01 12:07	obilodeau	Relationship added	related to 0001050
2010-12-01 12:09	obilodeau	Additional Information Updated
2010-12-01 14:47	obilodeau	Note Added: 0001784
2011-01-11 09:49	obilodeau	Note Added: 0001802
2011-01-11 09:49	obilodeau	Status	new => resolved
2011-01-11 09:49	obilodeau	Resolution	open => no change required
2011-01-11 09:49	obilodeau	Assigned To	=> obilodeau