Airport Resetting Issue

Question

Hi, I work at a apple care center on a university campus.
I have noticed an issue that has popped up since the last update of Leopard.
The issue involves a user doing a few things: having their computer sleep when connected to a airport connection, going from one airport connection to another, or dipping out of a connection hotspot and then back into it.
This is what happens, the airport signal shows that there is a connection but any web browser will not connect (any, firefox, safari, ie, etc.) It looks like airport is working, but once a browser is open the airport status switches to "searching" I believe.
I've manually turned off airport and gone in and reset the connection, but it still doesn't work.
So far there has only been one remedy - resetting the computer, and it works.
That said, has there been any other users that have noticed this update bug? I've been receiving a plethora of complaints that are of this issue.
Thanks,
ne0tr0pic

Answer 1

It sounds like the original poster is having issues with DHCP address renewal.
Remember that the Airport icon only indicates a valid association with a Wi-Fi router; I almost guarantee that a user seeing a valid association but unable to contact the Internet has a self-assigned IP address.
There, are, unfortunately some arguments going on (especially between Apple and Cisco) about how machines should behave when renewing DHCP addresses.
This page explains the issue in detail; the issue continues in Mac OS X Leopard:
Some time after obtaining a DHCP lease (entering the DHCP BOUND state), the client sends one or more DHCPDISCOVER packets. This implies the client has returned to the DHCP INIT state, relinquishing the old DHCP lease. In some cases, the client ignores all offers sent in response to the DHCPDISCOVER packet(s), or all those offers never reach the client (e.g. are dropped by the network). However, instead of remaining in the DHCP INIT state, the client continues to act as if the old DHCP lease is still in the BOUND state. It keeps using the IP address from the old lease (even trying to RENEW and later REBIND the old lease).
Because other DHCP clients may be leased the IP address after the first client relinquishes its lease on the address, the first client's continued use of that IP address interferes with service to those other clients.
I can positively confirm that the problem began no later than September 2005. At that time, Mac OS X 10.4.2 was the latest version of the OS available. Prior to then, I did not see the Mac OS X clients here exhibit this problem. Based on that, I believe the issue was introduced into Mac OS X in version 10.4.2 or earlier. Given that 10.4 was released in late April 2005, and the usage at our institution would tend to make it difficult to notice over the Summer (when most of our customers are away), I can imagine the problem may have been introduced as far back as version 10.4 or 10.4.1.
At Princeton, the problem has slowly grown from a rare occurence to a frequent problem. That's due to the growth in number of Mac OS X 10.4.x systems at our site, and due to the higher DHCP lease churn rate for each client (associated with the increasing use of wireless laptops that connect and disconnect often). At first I detected only a few incidents per month throughout our entire institution; by now I generally see several each day.
In many of these cases, our support staff have examined the malfunctioning Macs, and found no apparent problems. The devices appeared to be properly configured to use DHCP, with no special circumstances. (E.g. there was no second device forging the first one's hardware address or DHCP Client Identifier, no VM software running a separate DHCP client instance, no use of Apple's (or a third party) NAT software. There was nothing to indicate that there was a second DHCP client instance running using the same DHCP Client Identifier on the same network. It really appeared to be just simple Mac OS X DHCP clients, running current (at the time) versions of 10.4.x.)
After exhibiting the malfunction, the device may go weeks or months before exhibiting the malfunction (stealing an IP address) again...or it may happen again a few hours later. I know of no way to force any one device to reproduce the problem; I only am able to detect the problem the day after the fact, when I see "stolen IP address" problems by reviewing daily logs of unexpected DHCP server transactions and comparing them to IP usage data drawn from router ARP cache snapshots.
Apple's Take:
Apple has indicated to me that the Mac OS X DHCP client may indeed transition directly from the DHCP INIT state to the DHCP BOUND state.
The situation they describe is:
a) A client is in the DHCP BOUND state.
b) The DHCP client enters the INIT-REBOOT state, e.g. as a result of a sleep/wake cycle or link state change.
c) The DHCP client sends a DHCPREQUEST.
d) The DHCP client receives neither a DHCPACK or DHCPNAK.
(I note that in our case, the DHCPREQUEST may indeed have reached the DHCP server and the DHCP server sent a DHCPACK. Presumably this never reached the client.)
e) Their DHCP client chooses to stop using the old lease, although there is still time remaining on the lease.
(I note that RFC 2131 allows the client to continue using the old lease if it wishes, until the old lease expires.)
Instead, their client chooses to return to the DHCP INIT state.
f) The DHCP client sends a DHCPDISCOVER.
g) The DHCP client does not receive a DHCPOFFER.
(I note that in our case, the DHCPDISCOVER did indeed reach the DHCP servers, and the DHCP servers send DHCPOFFERs to the client. Presumably none of the multiple DHCPOFFERs reached the client (e.g. all are dropped by the network), or the client has gone selectively deaf to just these offers.)
h) The DHCP client sends an ARP request to the IP router that was its default gateway in the old lease. The router responds, and the client receives the response.
i) The DHCP client goes back to the DHCP BOUND state and resumes using the old lease. It will enter RENEWING and REBINDING state as usual.
Summary
Apple's stance is that sending a DHCP client can indeed go back to resume using the old lease; that sending a DHCPDISCOVER doesn't imply that client has abandoned that lease.
I believe that's not right; it appears to me that it is not permitted by the state transition diagram (Figure 5) in RFC 2131. And if what they're doing is DNAv4, RFC 4436 also makes it clear that what their client is doing is wrong.
So I believe that the behavior introduced in the Mac OS X 10.4.x DHCP client is not correct.
If your DHCP server makes use of the DHCPDISCOVER to decide that the old lease identified by (client identifier, subnet) has been abandoned by the client, this client behavior will cause a problem. That's because as far as the server is concerned, the old lease has been abandoned by the client, but the client proceeds to use that IP address. Your server may lease that IP address to another device.
And if you have equipment that monitors DHCP traffic to learn which IP addresses are leased to clients, the conclusions reached by that equipment will not always match that of Mac OS X 10.4.x clients.