I've been trying to follow this explanation, and I can't. Sending a response as unicast implies nothing about whether it is layer 2 or layer 3, and routing at layer 3 to a device that doesn't have a layer 3 address yet strikes me as Black Magic of the most heretical sort. I am not saying that the difference between DHCP and BOOTP, even perhaps specifically the difference between their use of broadcast and unicast, is not relevant to the issue being encountered. I am, however, saying that the reference to gratuitous ARP is at odds with what I think I know about TCP/IP, and that the only time a router should participate in the conversation is if DHCP/BOOTP requests are being relayed between the client subnet and a server on some other segment. (In fact, a "gratuitous ARP" is an unsolicited ARP *response* sent as a broadcast to inform clients that an IP address they may already have cached information for is associated with a new MAC address. It would be appropriate for a BOOTP client to advertise its newly-granted address that way since other devices should not have seen the unicast OFFER; it would be appropriate for a DHCP client to advertise its newly-granted address that way since other devices should not want or need to guess which of several offers it chose to accept. But in both cases it would come from the client after accepting an address offer, and not from a router as part of delivering one.)
David Gillett CISSP CCNP > -----Original Message----- > From: Marcelo Lew [mailto:m...@du.edu] > Sent: Wednesday, October 14, 2009 3:21 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs > > 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: m...@du.edu > > -----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: m...@du.edu > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:wireless-...@listserv.educause.edu] On Behalf Of > Anthony Croome > Sent: Tuesday, October 13, 2009 10:30 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > 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:wireless-...@listserv.educause.edu] On Behalf Of Earl Barfield > Sent: Friday, 28 August 2009 11:39 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs > > > Date: Thu, 27 Aug 2009 15:58:39 -0500 > > From: Hector J Rios <hr...@lsu.edu> > > 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: earl.barfi...@oit.gatech.edu e...@gatech.edu > > ********** > 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/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
