Macbook Pro: Network connectivity just disappears

Shortly after the 10.4.9 update, and even though I’m running 10.4.10, I’ve noticed an odd behavior with my wireless network connectivity. While using my machine, often for hours at a time without incident, my applications will all suddenly act as though there’s no internet, and indeed, looking at the routing tables, by all appearances it is gone.

The odd part is that my signal strength is at full. And, even more confounding, if I turn off the wireless and turn it back on, I suddenly get connectivity again and the applications recover. Meanwhile, other devices connected wirelessly don’t see the drop, so I know it’s local to the Macbook Pro.

Is anyone else out there experiencing a similar problem where the machine just drops internet awareness?

The only clue I ever seem to get in my console.log file is the message:
mDNSResponder: SetupAddr invalid sa_family 0
mDNSResponder: getifaddrs ifa_netmask for fw0(7) Flags 8863 Family 2 169.254.59.71 has different family: 0
mDNSResponder: Repeated transitions for interface en1 (FE80:0000:0000:0000:0216:CBFF:FEB6:AD8C); delaying packets by 5 seconds

According to websites with source code for the operating system, the file dDNS.c contain codes that looks like this:

mStatus dDNS_SetupAddr(mDNSAddr *ip, const struct sockaddr *const sa)
	{
	if (!sa) 
                { 
                LogMsg("SetupAddr ERROR: NULL sockaddr"); 
                return(mStatus_Invalid); 
                }

	if (sa->sa_family == AF_INET)
		{
		struct sockaddr_in *ifa_addr = (struct sockaddr_in *)sa;
		ip->type = mDNSAddrType_IPv4;
		ip->ip.v4.NotAnInteger = ifa_addr->sin_addr.s_addr;
		return(mStatus_NoError);
		}

	if (sa->sa_family == AF_INET6)
		{
		struct sockaddr_in6 *ifa_addr = (struct sockaddr_in6 *)sa;
		ip->type = mDNSAddrType_IPv6;
#if !defined(_WIN32)
		if (IN6_IS_ADDR_LINKLOCAL(&ifa_addr->sin6_addr)) 
                    ifa_addr->sin6_addr.__u6_addr.__u6_addr16[1] = 0;
#else
		if (IN6_IS_ADDR_LINKLOCAL(&ifa_addr->sin6_addr))
                    ifa_addr->sin6_addr.u.Word[1] = 0;
#endif 		
		ip->ip.v6 = *(mDNSv6Addr*)&ifa_addr->sin6_addr;
		return(mStatus_NoError);
		}

	LogMsg("SetupAddr invalid sa_family %d", sa->sa_family);
	return(mStatus_Invalid);
	}

It appears that the software can’t figure out whether IP4 or IP6 is in use, so it reports it has no idea how to set up the socket. It’s interesting to note that the socket isn’t null, so something’s going on.

But what is mDNSResponder? Well, for one, it contains Apple’s Bonjor services that allow zero-configuration networking.

mDNSResponder is a multi-cast DNS deamon. And, what’s even cooler, is that you can force it to emit its status and dump tons of info in the console.log by sending it a gentle signal:
sudo killall -INFO mDNSResponder

Even FreeBSD has mDNSResponder in its ports collection.

And, even while Apple has a way to disable Bonjour, I’m not sure that I want to, nor am I 100% convinced this is the problem, but is more likely a symptom. Afterall, Apple has had network problems before. Plus, they appear to be actively working on Bonjour.

As my friend Phil points out, the IP addresses in the 169.254 range are in the zero-configuration range for peer-to-peer communication.

Like I said, I’m curious to know if I’m alone in this, or even better, if someone’s solved the problem, what was it…?

UPDATE 1-Aug-2007: It appears that the AirPort Extreme Update 2007-004 fixes this problem. And, while you’re at it, get the Security Update 2007-007 as well.