Looking for something else on the Aruba knowledge base, I found this article, which might help out explain some of the issues with MACs and IP addresses:
There is a primary difference between Windows-based and Linux/Unix-based (this includes Apple OS X) DHCP clients. 1) Windows uses the newer DHCP DISCOVER process which is sent out as a broadcast (Layer 2). This broadcast is then responded to with a DHCP OFFER which is also broadcast back to the potential client. The client then sends back a DHCP REQUEST via unicast (Layer 3). The DHCP server then ACK (acknowledges) the request and normal TCP/IP communications can commence for the client. 2) Linux/Unix-based clients (including MAC OS X) use the older BOOTP method. The BOOTP DISCOVER is broadcast (Layer 2) out. The BOOTP OFFER is then sent back via unicast (Layer 3). This is the main difference between the two protocols. Being that the BOOTP OFFER is sent via Layer 3 instead of Layer 2, certain network topologies need to be considered. 3) When a BOOTP OFFER is sent back to the originating client, a gratuitous ARP must be done along the Layer 3 path. This is most important as it pertains to routers or Layer 3 switches. Since the client does not officially have an IP address yet, the Layer 3 device must populate its ARP cache with the MAC address of the client which is determined by the header of the BOOTP OFFER header. 4) In an instance where a BOOTP OFFER is made, but not accepted by the client, the MAC address of the client is still associated to the non-accepted IP address in all Layer 3 devices in the path. Where this becomes significant is when a BOOTP offer is made, not accepted, and then re-offered to another client within the ARP timeout period of a Layer 3 device. The BOOTP DISCOVER will be sent by a new client, but the OFFER will be sent via Layer 3 to the first device that had been offered the address. 5) Default values for industry routers and other network devices that support IP routing vary from vendor to vendor. Some ARP timeouts can be very low, and some users manually configure low ARP timeout values. If the scenario in item four happens within a timeout value of 4 minutes, this anomaly may present itself. 6) If your network has more than one DHCP/BOOTP server that is issuing offers, this may occur on a regular basis. When this is the case, you will notice that Windows clients are not having issues, but Mac and Linux clients are experiencing the issue. To circumvent or correct this potential problem, simply lower the ARP cache timeout on the Layer 3 devices in your network path. Remember, Layer 2 switches do not perform ARP, but simply cache the MAC address of directly connected devices. If you are using RADIUS to assign DHCP/BOOTP addresses, this anomaly will not occur. Marcelo Lew Wireless Network Specialist University Technology Services University of Denver Desk: (303) 871-6523 Cell: (303) 669-4217 Fax: (303) 871-5900 Email: [email protected] -----Original Message----- From: Marcelo Lew Sent: Wednesday, October 14, 2009 9:59 AM To: 'The EDUCAUSE Wireless Issues Constituent Group Listserv' Subject: RE: [WIRELESS-LAN] Self-assigned IP on Macs We have seen this with our Aruba system, but only on our 802.1x/wpa2 SSID. We usually uncheck PEAP on the 802.1x profile of MACs, so they use TTLS, which seems to work better. If this fails, we then delete the 802.1x profile and anything related in the keychain. Usually that works. Unchecking IPv6 (enabled by default) seemed to have helped in the past. After a code upgrade in our system the problem went away, however, we have seen issues again with Snow Leopard (won't get an IP address, they end up with a self-assigned. But if you look at logs, they really haven't authenticated successfully, but for some reason they won't see an error message). This doesn't happen on an open SSID of course. Marcelo Lew Wireless Network Specialist University Technology Services University of Denver Desk: (303) 871-6523 Cell: (303) 669-4217 Fax: (303) 871-5900 Email: [email protected] -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Anthony Croome Sent: Tuesday, October 13, 2009 10:30 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs Hi We are having this problem too. Is there any new information from people? We currently run Cisco wireless and have upgraded some locations to the new N standard. The problem "appears" to be isolated in the locations where we have upgraded but we can't be 100% sure. It is only appearing on macs, and they claim it works in one place but not another. All we can see is that it appears to be rejecting the dhcpoffer from the dhcp server. We haven't tried disabling dhcp proxy as discussed earlier in this thread, but others have said it didn't help. The latest temporary solution that has worked on two out of two macs is === All commands required at the command line: sudo ipconfig set en1 BOOTP (case sensitive and en1 is generally the wireless adapter on macs but it could possibly be different?) wait 5 seconds and then enter: sudo ipconfig set en1 DHCP === Anthony Croome QUT -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Earl Barfield Sent: Friday, 28 August 2009 11:39 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs > Date: Thu, 27 Aug 2009 15:58:39 -0500 > From: Hector J Rios <[email protected]> > Subject: Self-assigned IP on Macs... > > Have you guys run into this issue? We run Cisco's lightweight APs on > WiSMs running code 5.2.193. Mac will associate to our APs but just won't > obtain an IP address. In the end it assigns itself a self-assigned IP. > We are seeing this on a lot of new MacBooks and MacBookPros running > 10.5.8. If we associate the computer to an autonomous AP it works fine. > If we boot it in safe mode it works fine too. Everything else it just > fails. I had the same problem after ugrading from 4.2.<something> to 5.2.193.0. Uncheck "Enable DHCP Proxy" under controller->advanced->DHCP and see if that fixes it. It worked for me. -- Earl Barfield -- Academic & Research Tech / Information Technology Georgia Institute of Technology, Atlanta Georgia, 30332 Internet: [email protected] [email protected] ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
