Q: Dropping Wi FI Signal

Deleted: wrong typing.

Message was edited by: satcomer

california99 wrote:
No. This was a different setting. I actually don't know what this particular function is, but it sure did cause problems for Snow Leopard.

A little tale of how Microsoft gets you into trouble:

There's a flag in the header of DHCPDISCOVER packets that tells the DHCP server whether its responses should be broadcast to the entire link-layer network or unicast back to the requesting client.

The DHCP protocol states that if the broadcast flag is set, the client should ignore unicast responses, and if the broadcast flag is clear, the client should ignore broadcast responses.

The problem? NT 3.5 and Windows Vista originally set the broadcast flag for all DHCP traffic, causing DHCP problems where Vista machines could not obtain an address via DHCP:

http://support.microsoft.com/kb/928233

Microsoft addressed the issue by fixing DHCP in Vista (and in Windows 7) to not set the broadcast flag. So far, so good.

However, some vendors, in an effort to be more Vista-compatible, set their DHCP servers to always broadcast their responses.

You can see where this is headed - if Mac OS X sends a DHCP request with the broadcast flag clear, the protocol states responses should be sent via unicast.

So if the router is always sending its addresses using broadcast mode, if Mac OS X ignores broadcast responses when sending DHCPDISCOVER packets with the broadcast flag clear (because it expects a unicast response, and the protocol seems to indicate it's legal for it to do so), the result will be failure to obtain an address via DHCP.

Now where the issue may lie is in how Mac OS X handles this situation. Most DHCP clients try to work around this by sending requests with the broadcast flag clear, and if that fails to elicit a response from the DHCP server, the client will send requests with the broadcast flag set. (Or vice-versa.)

If Mac OS X is not trying both modes or if trying both modes takes too long, DHCP address acquisition can fail.

Note that this is not a bug per se, but rather an implementation artifact; it's up to the DHCP server to properly honor the broadcast flag.

This is but one example of how Mac OS X could properly adhere to all protocols and could have issues with third-party products that do not; a DHCP server that always broadcasts responses and so isn't adhering to the protocol for "compatibility" reasons that ironically in this case may actually cause breakage among some clients.

RFC 2131 is pretty clear on the subject:

A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit.

A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the 'yiaddr' field and the link-layer address specified in the 'chaddr' field. If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address.

http://www.ietf.org/rfc/rfc2131.txt

One experiment you can perform to see how your system is currently interacting with your router is to run the following command from a Terminal window:

ipconfig getpacket interface

Where interface is usually en0 for wired Ethernet, and en1 for AirPort.

In the output you'll see "flags" set to either "8000" or "0."

If it's 8000, the broadcast flag was set on the response packet; if it was 0, it was not.

Thanks for this terminal command. Now that I have run the experiment my flags = 0.

So what does this mean? I almost followed your comments, but can't quite put it all together. Should I want a zero or 8000?

Is this related to WiFiGuru's fix?
Network Settings -> Always Broadcast ( compatibility for some DHCP clients)
Uncheck this option.
Save Settings.

My mistake it was california99 with the fix:

Go to your router:
Network Settings -> Always Broadcast ( compatibility for some DHCP clients)
Uncheck this option.
Save Settings.

ctmurray wrote:
Thanks for this terminal command. Now that I have run the experiment my flags = 0.

So what does this mean? I almost followed your comments, but can't quite put it all together. Should I want a zero or 8000?

If "flags" is 0, it means that if you're speaking to a router that always enables broadcast (california99's fix from Apple explicitly shuts that option off in his D-Link), things may not work properly.

This is because Mac OS X has not set the Broadcast bit in the flags, and expects its DHCP responses to be sent via unicast.

The DHCP protocol heavily implies (depending on your interpretation of the words "SHOULD" and "MAY") that the client may ignore any responses that therefore are sent via broadcast, and if the router always responds using broadcast, you can see where two supposedly protocol compliant products get into an argument regarding its interpretation.

The fact that you can obtain an IP address via DHCP at least implies that your router's DHCP server follows the rules.

For the record, I've been through the Mac OS X DHCP client code and did not see where it would summarily ignore broadcast responses to unicast requests, but such handling may be performed at a protocol level before the client is ever passed received socket data:

http://www.opensource.apple.com/source/bootp/bootp-198/IPConfiguration.bproj/dhc p.c

However, given an Apple engineer suggested checking the DHCP broadcast setting on the router, that implies they at least know it can be an issue.

William Kucharski wrote:

ctmurray wrote:
Thanks for this terminal command. Now that I have run the experiment my flags = 0.

So what does this mean? I almost followed your comments, but can't quite put it all together. Should I want a zero or 8000?

If "flags" is 0, it means that if you're speaking to a router that always enables broadcast (california99's fix from Apple explicitly shuts that option off in his D-Link), things may not work properly.

This is because Mac OS X has not set the Broadcast bit in the flags, and expects its DHCP responses to be sent via unicast.

The DHCP protocol heavily implies (depending on your interpretation of the words "SHOULD" and "MAY") that the client may ignore any responses that therefore are sent via broadcast, and if the router always responds using broadcast, you can see where two supposedly protocol compliant products get into an argument regarding its interpretation.

The fact that you can obtain an IP address via DHCP at least implies that your router's DHCP server follows the rules.

For the record, I've been through the Mac OS X DHCP client code and did not see where it would summarily ignore broadcast responses to unicast requests, but such handling may be performed at a protocol level before the client is ever passed received socket data:

http://www.opensource.apple.com/source/bootp/bootp-198/IPConfiguration.bproj/dhc p.c

However, given an Apple engineer suggested checking the DHCP broadcast setting on the router, that implies they at least know it can be an issue.

So at least we have a case where what the Apple guy said to do makes some sense, thanks to your detailed understanding of the DHCP protocol. Thanks for contributing. I do have a Dlink router but have not yet had exactly the issues discussed. But I have to say that I have some annoying "delays", where I get a time out error, then immediately hit the try again button and immediately then get a connection. And there have been other Dlink users in this long thread, so at least they should try this change on the Dlink routers.

Would this issue (changing the Dlink settings in post above) also be solved by hardwiring you IP address with your router? Turn off DHCP and assign an IP address. Seems like it would from my limited understanding.

As this problem only affects DHCP, if you don't use DHCP, or your router is used as a bridge to an external DHCP server, you should be unaffected (assuming the upstream DHCP server doesn't suffer from the same issue.)

So yes, if you use a manual IP address for your Mac, you should not be affected by this or any other DHCP problem, as you can't get stuck with a "self-assigned" IP address if you're not using DHCP.

Yep -- and a few posters early on in this thread reported that maually assigning the IP address solved their particular problem. Doesn't seem to work for everybody, so the mystery remains.

Manually setting an IP address will only help those whose problems are due to a self-assigned IP address; it will do nothing for those who see true Wi-Fi dropouts as indicated by their signal strength bars going grey.

FWIW, I took my MBP 2,2 into the Genius Bar last week. Battery was shot, and I'm still having this wireless issue after a complete reinstall. I'm going to try resetting the PRAM and SMC, but honestly, I'm about ready to ditch the thing. I have a Linksys router, not a Dlink or 2wire as many of the posters are indicating. I got it when Vista started blowing up when using my old Linksys. It isn't signal quality, since I have a full signal when it happens, and it really looks like my DNS stops working.

After talking to the engineer from Comm Escalation, we confirmed that it wasn't my signal quality or anything. The guy at the Genius Bar deleted some preference files and said that's all he could do until I confirmed it wasn't software.

I can't keep justifying all the time/money spent trying break/fixes anymore. I'll take it in one more time, but this is getting out of hand. From what I'm hearing, even new hardware is having this issue.

William Riggins wrote:
It isn't signal quality, since I have a full signal when it happens, and it really looks like my DNS stops working.

If that's the case, have you tried manually specifying the use of a third-party DNS service in your Network preferences, like OpenDNS (208.67.222.222 and 208.67.220.220) or Google Public DNS (8.8.8.8 and 8.8.4.4?)

For many ISPs, DNS servers are something they have to have and don't generate revenue, so they just run them on whatever old hardware they have lying around. Specifying one of the services above also gets you around the DNS forwarders many routers have built in that, unfortunately, don't work as well as they should.

As far as my troubles go (airport stays connected with full bars, but network freezes), changing from dynamic to static dhcp doesn't change anything.

Still waiting (hoping for a solution)...
Apple...

I was referring to this exchange, Bill:
http://discussions.apple.com/message.jspa?messageID=11099198#11099198
Sorry if I misunderstood.

After much experimentation, in my case I've determined that the primary problem is temperature. I have installed coolbook and smcFanControl. By dropping the voltage to the cpu to .9 volts and keeping the fan speed at a minimum of 5000 rpm, the temperature of the airport card stays lower and the connection seems to be maintained. There may be some form of temperature protection built into the airport card, and when it turns the card off because of temperature the software is unaware and behaves erratically. Thus the symptom of showing full bars but not being connected (hardware monitor is a good tool to see all the temperature sensors in the computer).

But I've also had DHCP issues with the Actiontec modem/router. I have since connected my netgear router up to use for wireless. It has behaved much better in the past. I'm not very impressed with the actiontec. It is fairly limited in configuration items. That's probably why Qwest issues it as their standard dsl modem.

I suggest that those having problems with the airport disconnecting while showing full bars, then not being able to turn it on and off again (without restarting) check their operating temperatures using a tool such as hardware monitor.

Now I just need to find a way to run my mbp at full speed without cooking the airport card (and myself at times).

William Riggins wrote:
FWIW, I took my MBP 2,2 into the Genius Bar last week. Battery was shot, and I'm still having this wireless issue after a complete reinstall. I'm going to try resetting the PRAM and SMC, but honestly, I'm about ready to ditch the thing. I have a Linksys router, not a Dlink or 2wire as many of the posters are indicating. I got it when Vista started blowing up when using my old Linksys. It isn't signal quality, since I have a full signal when it happens, and it really looks like my DNS stops working.

After talking to the engineer from Comm Escalation, we confirmed that it wasn't my signal quality or anything. The guy at the Genius Bar deleted some preference files and said that's all he could do until I confirmed it wasn't software.

I can't keep justifying all the time/money spent trying break/fixes anymore. I'll take it in one more time, but this is getting out of hand. From what I'm hearing, even new hardware is having this issue.