Steve Litt <slitt@???> wrote:

>> uh? dhcp has nothing to do with wifi authentication, and you don't
>> need to know anything about ip or ifconfig if you are using a dhcp
>> client...
>
> In that case, I need to do a lot more studying of networking (which I
> knew), because everything I've seen tells me link, dhcp and network
> device operational kind of look like each other when the network
> doesn't come up on a laptop with wifi.

The basic process for bringing up a network connection goes :

(Physical) Interface discovered and made available to "the system" - kernel plus other stuff ? That's where some of the "discussion" regarding non-free drivers etc comes in.

Link on that interface goes into an active state.
For a wired interface, that simply means that the cable is plugged in and connected to another device (typically a switch) at the other end.
In the case of WiFi, it involves the discovery and selection of a suitable network, and connecting to that network (with authentication where required) - the process for that being a separate discussion to the one about non-free drivers.
This then triggers <something> to handle an if-up event.

That ip-up processing then looks at the network configuration set for the system.
Where a static address configuration is present, it's simply applied - "ip addr add ...", "ip route add ..." and so on.
Where DHCP is specified, then a DHCP client is spawned to handle the interface - typically putting itself into the background either immediately or after a short delay. Depending on the interface history*, the DHCP client will solicit information from the network in order to configure the interface.

At some indeterminate time later (could be a long time if there is a problem, eg DHCP server down), an IP address will be configured and the interface is ready for use.

Some problems, such as no response from a DHCP server may trigger other actions. For example, both OS X and Windows will eventually configure a link-local address on an interface.

* Basically, if the system has a reliable real-time clock, and the system has at least one unexpired lease, then the DHCP client will typically look to see if that lease is still valid for the network. Originally that was as simple as broadcasting a DHCP-Renew package and seeing if any DHCP server replies with a DHCP-Nack which would signify that the lease isn;t valid for this network. Many modern systems (I know OS X does this, and I think Windows too) will look at things like the MAC address of the gateway - if an ARP request for the previously known gateway router gets the same MAC address then you are almost certainly on the same network, and the unexpired lease is still valid.