Hi, We have seen on and off reports that Mac OS X registration is painful with PacketFence and that in most cases a reboot, disconnecting and reconnecting the SSID or waiting for several minutes was the 'fix'.
At some point we had problems with 10.5 and we were told that they were supposedly fixed in 10.6.. Lately the problem reoccurred and we decided to properly document it and take the time to see exactly what's going on. If it's hour fault, Mac OS X's fault and if something could be done about it. I filed a ticket earlier with the details. Here it is: http://www.packetfence.org/bugs/view.php?id=1132 #1132: Mac OS X DHCP issues after a VLAN change on wireless networks 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 Workaround: We are working on a workaround 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 change. 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! Thanks, -- Olivier Bilodeau [email protected] :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
