5 ms·
>I expect Apple will solve this problem in their usual way; pick slightly less stupid settings and lock those in. As someone who's dealt with the inimitable jo
by redthrowaway 15y ago
>I expect Apple will solve this problem in their usual way; pick slightly less stupid settings and lock those in.
As someone who's dealt with the inimitable joy of trying to get an MBP to work with an HDTV, Apple's "usual way" appears to be to code to the standards and to hell with anyone who breaks them (or the users stuck with non-compliant products). This appears to apply to wifi as well. There's been an open bug in OSX for years involving OSX assgining its own DHCP lease when it fails to negotiate one with the router. This results in the dreaded "Self-assigned IP" message, which is nigh-on impossible to rid yourself of short of voodoo dolls and wifi dances.
- jrmg 15y agoThis appears to apply to wifi as well. There's been an open bug in OSX for years involving OSX assgining its own DHCP lease when it fails to negotiate one with the router. This results in the dreaded "Self-assigned IP" message, which is nigh-on impossible to rid yourself of short of voodoo dolls and wifi dances. Getting a bit off-topic here, but that's not a bug: it's assigning itself a valid zeroconf* address because the DHCP server is not responding. * http://en.wikipedia.org/wiki/Zero_configuration_networking#Address_selection http://en.wikipedia.org/wiki/Zero_configuration_networking#A...
- kwamenum86 15y ago"code to the standards and to hell with anyone who breaks them" I think bug in this case just means that the software does not work as intended even though it follows the spec.
- calloc 15y agoYou can simply ask Mac OS X to request another DHCP address when it comes up with Self-assigned IP. The Self-assigned IP address is actually in a range that is specified in the RFC 3927 [1]. This is mainly done so that if it joins a network without a DHCP server it can still communicate with other hosts on the network, just not the outside. Also, in my experience Apple's DHCP agent will re-request an IP address after having assigned itself a self-assigned IP address. This generally takes about a minute or so, in that time the DHCP server can then reply once again. I've never had issues with this at all. [1] http://www.ietf.org/rfc/rfc3927.txt http://www.ietf.org/rfc/rfc3927.txt
- deleted 15y ago[deleted]
- ajross 15y agoWhen it joins a what now? There are no wifi networks without DHCP servers. At least there are none in the consumer electronics market to which zeroconf is targetted. Zeroconf is a historical mistake. It shouldn't be there any more; it does far more harm than good.
- wmf 15y agoI think the use case was ad-hoc wi-fi networks. But getting back to the original complaint, if not for zeroconf you'd have no IP address at all; I don't see how that's any better.
- redthrowaway 15y agoThe problem is that OSX's behaviour (and not, notably, Windows') is to try once then fail as a "good enough" solution. It may indeed keep trying, but it's a problem that Windows never runs into in the first place. I'll admit to having only a rudimentary knowledge of how wireless networks work, but it's better than 99% of users and I find OSX frustrating (in this regard). At the end of the day, the user doesn't care whether the router manufacturer isn't following the spec, or whether Apple's implementation is buggy. The simple fact is that it works on Windows but not on OSX, and that's a failure on Apple's part.
- calloc 15y agoThis behaviour is the same on Windows. If Windows doesn't receive a DHCP address is will assign one in the self-assigned range first. After about a minute or so it too will re-request an IP address from the DHCP server and if it receives one it will assign that to the interface. What Windows does do wrong is that it then also drops the self-assigned IP address which may already be in use for communication, this can cause issues with other hosts that are communicating with it over zeroconf.
- 15y ago