The IP theft function can't trigger until the controller
actually see an IP in use. So they wouldn't exclude the
client before it had even tried to use an address much less
completed the dhcp process. The exclusion triggered BECAUSE
of the 192.168.1.x address. I also believe in packet
captures that we saw DHCPREQUEST packets from the client
asking for a specifc 192.168.1.x address. This seems to
indicate it was using the address previously. The server
answered with an DHCPOFFER from a different configured
range. The client however would not take it or did not get
it. When the "IP theft" function was turned off the client
would then complete the dhcp process normally. Also, this
did not always happen. From talking to one student it was
generally exhibited when he first came in and had used the
host on his home network previously.
-Matt
Methven, Peter J wrote:
Just for information MAC OS/X Leopard (and probably Tiger) both default
to an IP Address in the 192.168.1.n range when they cannot acquire an IP
address, like windows machines default to a 169.254.n.n ip address.
Presumably if they are being "excluded" from network access and not
acquiring an IP address from DHCP they will fall back to a self-assigned
IP address.
Many Thanks
Peter
-----Original Message-----
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Matt Grover
Sent: 28 August 2009 15:10
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs...
We have seen this issue to some degree. It did not happen
to all Macs but only to a small percentage of machines. In
case anyone should run into it though what I found was the
following...
It is normal for dhcp clients to request their last used IP.
Something about how the Mac dhcp clients were doing it
seemed to be different though. I haven't had time to do a
thorough analysis of Mac dhcp behavior. That aside, what I
noticed was that the clients having the trouble showed up in
the controller logs as being put into an "Exclusion" state.
This was because the controllers security mechanism was
kicking in and excluding the client because of "IP theft or
reuse". By disabling the "IP theft or Reuse" under
security, wireless protection policies, client exclusion
policies caused it to stop happening.
Looking into it further, the clients that were being blocked
were coming in with addresses in the 192.168.1.x range.
This is probably the most common range for home networking
so it's no surprise they would have that address range
coming in from home. I see two possibilities why it
triggered "IP theft". The first possibility is that another
client had come in under that address and the second one
gets blocked. The more likely cause I think is that we have
the service vlan on the controllers numbered in the
192.168.1.0/24 subnet just as the wism setup docs show. I
think this IP space is colliding with the clients coming in
and trying to use it. My guess is that the controllers see
the space in use by themselves and flag it. I have not had
time however to test this theory. I also do not know why
the problem was only exhibited by Macs. Seems to be
something different in their dhcp client behavior.
-Matt
----- Original Message -----
*From:* Hector J Rios <mailto:hr...@lsu.edu>
*To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
*Sent:* Thursday, August 27, 2009 3:58 PM
*Subject:* [WIRELESS-LAN] 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.
Thanks,
Hector Rios
Louisiana State University
--
------------------------------------------------------------
Matt Grover === University of Florida
Sr. Network Engineer === http://net-services.ufl.edu
m...@ufl.edu === Florida Lambda Rail
(352)273-1061 === http://www.flrnet.org/
------------------------------------------------------------
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
