Hacker News Reader

Comment by redthrowaway | Hacker News Reader

>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.

View on HN

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.

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#A...

"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.

You 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

I've had numerous issues on my university's network with the DHCP lease. They have a stupid VPN setup, so that may have helped fuck it up.

When 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.

I 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.

The 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.

This 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.

This dates back to long before wifi was widely available--the original use case was ad-hoc wired networks, where people with backgrounds in old-school AppleTalk-based Mac networking were expecting any two Macs with a cable between them to be able to talk to each other with no supporting infrastructure.

Create a WiFi network on one Mac, join it with another Mac. No DHCP server is running, but thanks to the self-assigned IP fallback, the two Macs can still communicate with each other. This can be tremendously useful.

This depends off course on how you create the wireless network. If you create one by routing another network such as using Network Sharing a DHCP server is set up since now it acts as a router.

You are correct for Ad-Hoc networks.

Reply on news.ycombinator.com