&*#%$(&#$ Apple's "Self-Assigned IP Address" bug

[JC Dill]

I run into this periodically, often when traveling and trying to use a
coffee shop or hotel WiFi network. There's a long standing bug in OS X
where the DHCP handshake doesn't work right, and Apple's "solution" is
to give the computer a self-assigned IP starting with 169. which is a
non-routable IP address. This is a completely USELESS "solution".
People have been complaining about this in Apple forums for YEARS:

<http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>

Sometimes rebooting the router helps. Sometimes it does not help. When
I am at a coffee shop or hotel I can't just be demanding they reboot
their router because my computer is stupid and can't properly handshake
with their router.

I'm hoping someone here has figured out a work-around, some way to tell
the apple TCP/IP service to not use this "feature" so that it WAITS for
the DHCP handshake to finish and receive a routable IP address from the
router.

jc

[Jeff Liebermann]

On Sun, 10 Jun 2012 19:16:17 -0700, JC Dill <jcdill...@gmail.com>
wrote:

>I run into this periodically, often when traveling and trying to use a
>coffee shop or hotel WiFi network. There's a long standing bug in OS X
>where the DHCP handshake doesn't work right, and Apple's "solution" is
>to give the computer a self-assigned IP starting with 169. which is a
>non-routable IP address. This is a completely USELESS "solution".
>People have been complaining about this in Apple forums for YEARS:
>
><http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>
>
>Sometimes rebooting the router helps. Sometimes it does not help. When
>I am at a coffee shop or hotel I can't just be demanding they reboot
>their router because my computer is stupid and can't properly handshake
>with their router.

True. However, you can retry the connection from your end. First try
just enable/disable your Airport card from the icon on the top of your
screen. If that doesn't work, try:
System Prefs -> Network -> Airport -> Advanced ->
TCP/IP -> Renew DHCP Lease

>I'm hoping someone here has figured out a work-around, some way to tell
>the apple TCP/IP service to not use this "feature" so that it WAITS for
>the DHCP handshake to finish and receive a routable IP address from the
>router.

RFC3927. Also known as APIPA, zeroconf, self assigned IP, or auto-IP.
<http://en.wikipedia.org/wiki/Link-local_address>
<http://en.wikipedia.org/wiki/Zero_configuration_networking>
The problem is not a bug in Apple's implementation of TCP/IP. The
problem is that the MAC address to IP table in the cheapo routers used
at most coffee shops and some hotels is full. The default behavior is
for the router to save the MAC to IP table in NVRAM in case the laptop
goes to sleep. However, the default behavior is to save it for days
in case the laptop returns and wants to re-use the same IP address.

Disabling auto-IP on your MacBook isn't going to help if the routers
MAC to IP table is full. After 254 table entries, there just aren't
any more IP addresses to assign. The proper behavior would be to
discard least recently used entries and replace them with your laptops
MAC and IP address pair. Manually forcing your laptop with a fixed IP
address will work, but only if you're lucky and don't re-use an
existing IP address. I've had to do this a few times when rebooting
the router isn't possible.

Also, like most wireless drivers, the Mac is rather stupid when
resuming from standby. It thinks it's still connected to the last
wireless router at its previous location and will continue to renew
the connection until convinced otherwise. On a PC, one has to invoke:
ipconfig /release
ipconfig /renew
to kick the driver into cooperation. On the Mac, this is done by
turning the Airport card on and off.

To the best of my limited Apple knowledge, there's no way to disarm
this auto-IP on the Mac.

--
Jeff Liebermann je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

[JC Dill]

On 10/06/12 8:17 PM, Jeff Liebermann wrote:
> On Sun, 10 Jun 2012 19:16:17 -0700, JC Dill<jcdill...@gmail.com>
> wrote:
>
>> I run into this periodically, often when traveling and trying to use a
>> coffee shop or hotel WiFi network. There's a long standing bug in OS X
>> where the DHCP handshake doesn't work right, and Apple's "solution" is
>> to give the computer a self-assigned IP starting with 169. which is a
>> non-routable IP address. This is a completely USELESS "solution".
>> People have been complaining about this in Apple forums for YEARS:
>>
>> <http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>
>>
>> Sometimes rebooting the router helps. Sometimes it does not help. When
>> I am at a coffee shop or hotel I can't just be demanding they reboot
>> their router because my computer is stupid and can't properly handshake
>> with their router.
>
> True. However, you can retry the connection from your end. First try
> just enable/disable your Airport card from the icon on the top of your
> screen. If that doesn't work, try:
> System Prefs -> Network -> Airport -> Advanced ->
> TCP/IP -> Renew DHCP Lease

I've tried that numerous times at numerous different locations (coffee
shops, hotels, etc.) without success. Trust me, I've googled and read
ALL the "fixes" for this problem but none of them Actually Fix The Problem.

>> I'm hoping someone here has figured out a work-around, some way to tell
>> the apple TCP/IP service to not use this "feature" so that it WAITS for
>> the DHCP handshake to finish and receive a routable IP address from the
>> router.
>
> RFC3927. Also known as APIPA, zeroconf, self assigned IP, or auto-IP.
> <http://en.wikipedia.org/wiki/Link-local_address>
> <http://en.wikipedia.org/wiki/Zero_configuration_networking>
> The problem is not a bug in Apple's implementation of TCP/IP.

I beg to differ.

There's something wrong with how Apple does this. If I use the method
above to renew the DHCP lease, sometimes it pops back up with the 169
address within micro-seconds, far less time than it normally takes to
actually release and renew a DHCP address. There's something WRONG with
how Apple does it, that the Mac's WiFi client decides it isn't getting
an IP from the remote DHCP server and decides to issue a self-assigned
IP address instead, when in the normal course of getting a DHCP address
it would be less 10% of the way into the amount of time it normally
takes to complete the process.

There are ~24,000 pages on apple.com where people are complaining about
this problem. All these people aren't imagining things. I haven't seen
an actual fix or solution posted yet - just some workarounds that might
work for some people, some of the time.

The
> problem is that the MAC address to IP table in the cheapo routers used
> at most coffee shops and some hotels is full. The default behavior is
> for the router to save the MAC to IP table in NVRAM in case the laptop
> goes to sleep. However, the default behavior is to save it for days
> in case the laptop returns and wants to re-use the same IP address.

This problem ONLY occurs for Mac computers. Someone else who comes in
after and opens a Windoze laptop has no problem getting an IP address.
Refresing the Mac gets the same self-assigned 169 address. Over and
over and over.

(Really. I'm not making this up.)

It's clearly not the router's fault if most of the laptops can connect
fine and everyone who is having problems has a Mac.

> Disabling auto-IP on your MacBook isn't going to help if the routers
> MAC to IP table is full. After 254 table entries, there just aren't
> any more IP addresses to assign. The proper behavior would be to
> discard least recently used entries and replace them with your laptops
> MAC and IP address pair. Manually forcing your laptop with a fixed IP
> address will work, but only if you're lucky and don't re-use an
> existing IP address. I've had to do this a few times when rebooting
> the router isn't possible.

I've tried it, with limited success. I'm looking for a SOLUTION, where
the process to "self assign" is removed so that the Mac actually WAITS
for the DHCP server to reply with an address rather than per-emptively
deciding to self-assign.

> Also, like most wireless drivers, the Mac is rather stupid when
> resuming from standby. It thinks it's still connected to the last
> wireless router at its previous location and will continue to renew
> the connection until convinced otherwise. On a PC, one has to invoke:
> ipconfig /release
> ipconfig /renew
> to kick the driver into cooperation. On the Mac, this is done by
> turning the Airport card on and off.
>
> To the best of my limited Apple knowledge, there's no way to disarm
> this auto-IP on the Mac.

When this problem happened today, my mac had been in sleep mode, with
wifi turned off. I plugged it in, let it un-sleep, turned wifi on, and
then it decided to give itself a self-assigned IP address. I asked the
person at the next table (who was on a Windoze system) if the wifi was
working for his computer, and it was working, no problem.

This has happened over and over and over, for years. I'm SO fed up with
it. What is really astounding is the number of posts on apple.com help
boards without a solution being posted! It's not as if Apple doesn't
know about this problem. They just apparently think they don't need to
fix it. Grrrrrrr.

jc

[Thad Floryan]

On 6/10/2012 11:30 PM, JC Dill wrote:
> [...]

> When this problem happened today, my mac had been in sleep mode, with
> wifi turned off. I plugged it in, let it un-sleep, turned wifi on, and
> then it decided to give itself a self-assigned IP address. I asked the
> person at the next table (who was on a Windoze system) if the wifi was
> working for his computer, and it was working, no problem.
>
> This has happened over and over and over, for years. I'm SO fed up with
> it. What is really astounding is the number of posts on apple.com help
> boards without a solution being posted! It's not as if Apple doesn't
> know about this problem. They just apparently think they don't need to
> fix it. Grrrrrrr.

I could make some, ahem, comments about Apple and why everything under my
purview is an Apple-free zone, but I won't. :-)

By any chance have you examine the system's log files?

On Windows systems the "Event Viewer" is the first place I visit when
helping folks with their Windows problems.

On Linux and UNIX it'll be the /var/log entries since users typically
cannot explain the problem(s) in a clear and coherent manner.

MacOS is ostensibly a UNIX-like system so it "should" have some error
logging capabilities whose results would be in var/log.

Alternately, get some payback on what you spent on your Mac and visit
one of the, what, so-called "genius" bars and have them fix the problem
otherwise visit Jobs' grave and pound some sand thereupon to exorcise
your frustrations. :-) :-) :-)

[JC Dill]

On 11/06/12 1:26 AM, Thad Floryan wrote:
> On 6/10/2012 11:30 PM, JC Dill wrote:
>> [...]
>> When this problem happened today, my mac had been in sleep mode, with
>> wifi turned off. I plugged it in, let it un-sleep, turned wifi on, and
>> then it decided to give itself a self-assigned IP address. I asked the
>> person at the next table (who was on a Windoze system) if the wifi was
>> working for his computer, and it was working, no problem.
>>
>> This has happened over and over and over, for years. I'm SO fed up with
>> it. What is really astounding is the number of posts on apple.com help
>> boards without a solution being posted! It's not as if Apple doesn't
>> know about this problem. They just apparently think they don't need to
>> fix it. Grrrrrrr.
>
> I could make some, ahem, comments about Apple and why everything under my
> purview is an Apple-free zone, but I won't. :-)
>
> By any chance have you examine the system's log files?
>
> On Windows systems the "Event Viewer" is the first place I visit when
> helping folks with their Windows problems.
>
> On Linux and UNIX it'll be the /var/log entries since users typically
> cannot explain the problem(s) in a clear and coherent manner.
>
> MacOS is ostensibly a UNIX-like system so it "should" have some error
> logging capabilities whose results would be in var/log.

What am I looking for in the log?

Here are the first few lines from when I booted up yesterday at the
coffee shop:


10/06/12 6:28:10 PM Alarm Clock[191] kIOMessageSystemHasPoweredOn
10/06/12 6:28:10 PM StatusMenu[183] receiveSleepNote:
NSWorkspaceDidWakeNotification
10/06/12 6:28:10 PM [0x0-0x20020].com.digitallity.alarmclock2[191]
2012-06-10 18:28:10.723 helper[16435:10b] Deleting power event:
2012-06-17 04:30:00 -0700
10/06/12 6:28:11 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:11 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:11 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:11 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:18 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:18 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:51 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:51 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:55 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:28:55 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:29:27 PM com.apple.launchd[153] (0x110d10.Locum[16460])
Exited: Terminated
10/06/12 6:30:03 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:30:03 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:30:49 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:30:49 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:31:08 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:31:08 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:31:51 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:31:51 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:31:51 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:31:51 PM com.apple.coreservicesd[55] NOTE: Using
non-mach-based version of client -> server communication, via direct
function calls.
10/06/12 6:58:57 PM com.jft.PdaNetMac[16420] before listening on daemon
socket
10/06/12 6:58:57 PM com.jft.PdaNetMac[16420] CDaemonCon2 exits
10/06/12 7:18:05 PM [0x0-0x114114].com.apple.finder[3196] Sun Jun 10
19:18:04 Somethingroyal Finder[3196] <Error>: CGImageCreate: invalid
image size: 0 x 0.


When I tried to connect to the coffee shop wifi and got a 169 address, I
then hooked up my android phone in tethering mode and used that for a
while. At some later point I was looking in finder in the "cover view"
mode, and during that time the console logged a number of jpeg errors.

> Alternately, get some payback on what you spent on your Mac and visit
> one of the, what, so-called "genius" bars and have them fix the problem
> otherwise visit Jobs' grave and pound some sand thereupon to exorcise
> your frustrations. :-) :-) :-)

I've tried that. The problem is sporadic, and only occurs at other
locations such as coffee shops and hotels, and rebooting the router
often fixes it (so if I were to find a router where this problem
regularly occurred, I couldn't just borrow the router when I go to the
Apple store, as the process of taking it to the store would necessarily
involve rebooting the router). The wifi works fine at the Apple store.
They can't fix it if they can't see it.

Given that nobody, in the many years this bug has been ongoing, has
posted that they got it fixed by Apple, leads me to believe that Apple
doesn't actually HAVE a fix. The Geniuses at the Genius Bar can't
magically create fixes out of thin air.

jc

[bi...@mix.com]

JC Dill <jcdill...@gmail.com> writes, quoting Thad Floryan:

> > I could make some, ahem, comments about Apple and why everything under my
> > purview is an Apple-free zone, but I won't. :-)

Go ahead - some of us could use a good laugh. Heh.

> > By any chance have you examine the system's log files?

> What am I looking for in the log?

This kind of stuff (searching on 'airport') -

6/9/12 9:17:19 AM kernel AirPort: Link Down on en1
6/9/12 12:18:56 PM kernel AirPort: Link Up on en1
6/9/12 6:37:40 PM kernel AirPort: Link Down on en1
6/10/12 8:13:18 AM kernel AirPort: Link Up on en1
6/10/12 3:51:39 PM kernel AirPort_Brcm43xx::probe: 021bfa00, 0
6/10/12 3:51:50 PM kernel AirPort_Brcm43xx: Ethernet address 00:0a:95:f7:e7:45
6/10/12 3:52:05 PM kernel AirPort: Link Down on en1
6/10/12 3:52:07 PM kernel AirPort: Link Up on en1

Unfortunately, though, this is probably about all you would find.
Not very informative when it comes to troubleshooting...

Searching for dhcp returns nothing, at least for me, on OS 10.5.8.

> When I tried to connect to the coffee shop wifi and got a 169 address

As Jeff L. pointed out, this (169.254/16) is a self-assigned address block.
It's the address with which your computer attempts to talk to a DHCP server
to request a routable IP address.

Anyway, since Apple is not logging very much, it would be helpful to look
at the logs of access points/routers where you are having this problem.
I don't know if that's possible, but I would give it a try.

When I see people having this problem at work, I pick up the phone and
call Bangalore (luckily Capgemini has a reasonably intelligent staff)
and ask them to clean up the dhcp pool. That always fixes it.

> I've tried that. The problem is sporadic, and only occurs at other
> locations such as coffee shops and hotels, and rebooting the router
> often fixes it (so if I were to find a router where this problem
> regularly occurred, I couldn't just borrow the router when I go to the
> Apple store, as the process of taking it to the store would necessarily
> involve rebooting the router). The wifi works fine at the Apple store.
> They can't fix it if they can't see it.

Well, if someone will restart the router for you, looking at its logs
doesn't sound so difficult.

What kind of encryption is in use at these various (working & nonworking)
places? What kinds of access points & routers work, and what doesn't?
What version of Mac OS are you running, and on which hardware?

> Given that nobody, in the many years this bug has been ongoing, has
> posted that they got it fixed by Apple, leads me to believe that Apple
> doesn't actually HAVE a fix. The Geniuses at the Genius Bar can't
> magically create fixes out of thin air.

As you said, Apple can't fix what they can't see. I have plenty of
complaints about their stuff, but this (wifi trouble) has not been
one of them.

Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number

[Jeff Liebermann]

On Sun, 10 Jun 2012 23:30:10 -0700, JC Dill <jcdill...@gmail.com>
wrote:

>It's clearly not the router's fault if most of the laptops can connect
>fine and everyone who is having problems has a Mac.

Ok, I'm convinced.

Maybe seeing what happens during the DHCP negotiations will help:
<http://www.sustworks.com/site/prod_ipmx_overview.html>
21 day free trial. Try the DHCP test at home and at the coffee shop.
Compare results. I'm stuck on 10.5 so I can't try it.

The trick will be to find out at what point during the negotiation
does it fail. Note that auto-IP will kick in no matter where it
fails, so you can't use it for diagnostics. A single connection
progress report on Windoze XP can end up 200 lines long, so it's
obviously not a simple exercise.

These look interesting. It sorta hints that it will provide
statistics and logging but I can't tell until I try it.
<http://osxdaily.com/2012/02/28/find-scan-wireless-networks-from-the-command-line-in-mac-os-x/>
<http://osxdaily.com/2007/01/18/airport-the-little-known-command-line-wireless-utility/>
<http://osxdaily.com/2011/06/15/get-detailed-wifi-info-from-the-menu-bar/>

More light reading. Looks like disabling DHCP seems to a recommend
fix.
<http://osxdaily.com/2009/09/01/how-i-fixed-my-dropping-wireless-airport-connection-problem-in-snow-leopard/>
Also looks like Apple has been working on the problem for 10.6.3 with
some airport and wireless fixes:
<http://support.apple.com/kb/HT4014>

If none of these offer a connection progress trace log, then sniffing
the traffic, capturing a log, and decoding it with Wireshark would be
the next step.
<http://www.sniffwifi.com>
<http://sharkfest.wireshark.org/sharkfest.08/T1-6_Wright%20and%20Kershaw_Leveraging%20Wireshark%20for%20Net%20Analysis.ppt>
47 PPT pages.
<http://www.wireshark.org>
Looks too much like real work.

>I've tried it, with limited success. I'm looking for a SOLUTION, where
>the process to "self assign" is removed so that the Mac actually WAITS
>for the DHCP server to reply with an address rather than per-emptively
>deciding to self-assign.

Like I mumbled, killing the auto-IP feature isn't going to do
anything. The network software assigns the 169.254.xxx.xxx address
only *after* DHCP fails to negotiate a proper IP address. If you turn
off auto-IP, all that will change is that you'll get a blank IP
address instead. The problem is probably in the DHCP negotiation.

>I asked the
>person at the next table (who was on a Windoze system) if the wifi was
>working for his computer, and it was working, no problem.

Ok, that's different from what I see when the MAC to IP address table
overflows. When it fills, no new connections can be established from
any device. So, that's not the problem.

>This has happened over and over and over, for years. I'm SO fed up with
>it. What is really astounding is the number of posts on apple.com help
>boards without a solution being posted! It's not as if Apple doesn't
>know about this problem. They just apparently think they don't need to
>fix it. Grrrrrrr.

Now you know why I switched to Android. Problems with older Apple
products are never fixed. Windoze XP is now 10 years old and will
remain supported for another two years. Any Apple products from 2002
which are still supported?

Your analysis is probably correct. As further evidence, I've had the
displeasure of dealing with various Airport base station problems. I
have about 5 of the mushroom shaped Airport BS that were removed from
service due to a mix of compatibility and reliability problems. I'm
also experiencing minor issues with combinations of iPad 2 versus
various 2wire wireless routers (mostly 2701HG). Yeah, something is
wrong.

[Jeff Liebermann]

On Mon, 11 Jun 2012 17:40:43 +0000 (UTC), bi...@MIX.COM wrote:

>As Jeff L. pointed out, this (169.254/16) is a self-assigned address block.
>It's the address with which your computer attempts to talk to a DHCP server
>to request a routable IP address.

Nope. The laptop finds the DHCP server by issuing a DHCP request
broadcast. In effect, it sends a broadcast packet to the entire
network asking if there's a DHCP server available that can supply a
usable IP address. When that fails, or no such server is found, the
laptop then assigns a local IP address of 169.254.xxx.xxx so that it
can connect to a diagnostic server in the same IP block.

>When I see people having this problem at work, I pick up the phone and
>call Bangalore (luckily Capgemini has a reasonably intelligent staff)
>and ask them to clean up the dhcp pool. That always fixes it.

Yeah, that's the problem that I was hinting. When the MAC to IP
address table is full, or the ARP cache is full of trash, then a
reboot will help, but only if these tables are not saved in NVRAM (as
it is by default with DD-WRT).

>Well, if someone will restart the router for you, looking at its logs
>doesn't sound so difficult.

I have yet to see a coffee shop wireless router that offers much
beyond syslog or maybe SNMP traps. Usually, all the logging is on
Layer 3 (IP layer). In order to do connection progress logging, it
needs Layer 2 (MAC layer) logging. There are access points that do
this, but they're not commonly found in coffee shops.

[JC Dill]

On 11/06/12 10:40 AM, bi...@MIX.COM wrote:
> JC Dill<jcdill...@gmail.com> writes, quoting Thad Floryan:
>
>>> I could make some, ahem, comments about Apple and why everything under my
>>> purview is an Apple-free zone, but I won't. :-)
>
> Go ahead - some of us could use a good laugh. Heh.
>
>>> By any chance have you examine the system's log files?
>
>> What am I looking for in the log?
>
> This kind of stuff (searching on 'airport') -
>
> 6/9/12 9:17:19 AM kernel AirPort: Link Down on en1
> 6/9/12 12:18:56 PM kernel AirPort: Link Up on en1
> 6/9/12 6:37:40 PM kernel AirPort: Link Down on en1
> 6/10/12 8:13:18 AM kernel AirPort: Link Up on en1
> 6/10/12 3:51:39 PM kernel AirPort_Brcm43xx::probe: 021bfa00, 0
> 6/10/12 3:51:50 PM kernel AirPort_Brcm43xx: Ethernet address 00:0a:95:f7:e7:45
> 6/10/12 3:52:05 PM kernel AirPort: Link Down on en1
> 6/10/12 3:52:07 PM kernel AirPort: Link Up on en1

The LINK is not down. (Layer 2 in the OSI model.) The computer sees
the available wifi network. One often recommended work-around for
people who encounter this problem with their home wifi is to set a
static IP instead of using DHCP, and then they have no more problems.

It's something in the DHCP part that doesn't work. DHCP is a Layer 7
item (an application layer), according to wikipedia.

http://en.wikipedia.org/wiki/OSI_model

> Unfortunately, though, this is probably about all you would find.
> Not very informative when it comes to troubleshooting...
>
> Searching for dhcp returns nothing, at least for me, on OS 10.5.8.
>
>> When I tried to connect to the coffee shop wifi and got a 169 address
>
> As Jeff L. pointed out, this (169.254/16) is a self-assigned address block.

I KNOW THAT. I'M USING "got a 169 address" AS SHORTHAND INSTEAD OF
WRITING OUT "a (169.254/16) self-assigned address block" each time.

I know what is happening. What I don't know is how to tell the computer
to WAIT for the DHCP process to complete, or alternatively how to simply
stop the computer from giving itself the 169 address (which is, as I
noted before, entirely useless). As I noted in my first post, when
renewing the DHCP lease, the computer "finishes" FAR too quickly to have
actually sent a DHCP request and waited to get the reply back.
Something is FUBAR in the DHCP process.

> It's the address with which your computer attempts to talk to a DHCP server
> to request a routable IP address.
>
> Anyway, since Apple is not logging very much, it would be helpful to look
> at the logs of access points/routers where you are having this problem.
> I don't know if that's possible, but I would give it a try.

It is not possible. This happens at coffee shops, hotels, etc. I'm
lucky if they even know where the router is, and if they are willing to
reboot it. Beyond that, no chance of getting anyone to let me log in
and look at the access logs.

>> I've tried that. The problem is sporadic, and only occurs at other
>> locations such as coffee shops and hotels, and rebooting the router
>> often fixes it (so if I were to find a router where this problem
>> regularly occurred, I couldn't just borrow the router when I go to the
>> Apple store, as the process of taking it to the store would necessarily
>> involve rebooting the router). The wifi works fine at the Apple store.
>> They can't fix it if they can't see it.
>
> Well, if someone will restart the router for you, looking at its logs
> doesn't sound so difficult.

They restart the router by power cycling it. They don't have the login,
nor would they let a total stranger login to the router even if they
knew how.



> What kind of encryption is in use at these various (working& nonworking)
> places? What kinds of access points& routers work, and what doesn't?


I have no idea about what type of router. It happens frequently, at
many different places. It's happened at Starbucks, Day's Inn, and 3 or
4 different (non-chain) coffee shops in the past 2 months. Most of
them have no encryption. The Day's Inn had encryption - I forget what
type. They had dozens of per-diem resident guests (working on a road
crew on a highway construction site a few miles down the road) who were
having no problems using the wifi. This was out in the middle of BFE
(Chambers AZ), where there is nothing but jackrabbits for miles, no IT
department to assist, etc.

> What version of Mac OS are you running, and on which hardware?

Please take a look at the apple website, using the link I posted at the
beginning of the thread:

<http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>

There are almost 24,000 different posts from people with this same
problem. The OS version and hardware version does not matter. People
have been having this problem for years on many different OSs, many
different computers (laptop and desktop).

>> Given that nobody, in the many years this bug has been ongoing, has
>> posted that they got it fixed by Apple, leads me to believe that Apple
>> doesn't actually HAVE a fix. The Geniuses at the Genius Bar can't
>> magically create fixes out of thin air.
>
> As you said, Apple can't fix what they can't see. I have plenty of
> complaints about their stuff, but this (wifi trouble) has not been
> one of them.

Lucky you. It's maddening when it happens (yet again) and you know
there's no way to fix it.

jc

[JC Dill]

On 11/06/12 11:23 AM, Jeff Liebermann wrote:
> Like I mumbled, killing the auto-IP feature isn't going to do
> anything. The network software assigns the 169.254.xxx.xxx address

> only*after* DHCP fails to negotiate a proper IP address. If you turn

> off auto-IP, all that will change is that you'll get a blank IP
> address instead.

It might pop-up a message if that happened. Instead it silently
pretends it has established network connectivity. Until you actually
try to use the network and find out that you don't have a working
connection.

> The problem is probably in the DHCP negotiation.

The problem is DEFINITELY in the DHCP negotiation. I'm trying to figure
out a way to keep it from quitting so fast, or to make it try again.

jc

[Jeff Liebermann]

On Mon, 11 Jun 2012 21:03:58 -0700, JC Dill <jcdill...@gmail.com>
wrote:

>Please take a look at the apple website, using the link I posted at the
>beginning of the thread:
>
><http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>
>
>There are almost 24,000 different posts from people with this same
>problem.

Try putting a plus sign in front of the word "bug" on the Google
search line. That makes the search require the word "bug" in the
results. It goes from 9800 hits to zero. I got the same results with
the word "problem".

You're correct that many people are failing to get a DHCP assigned IP
address, but none are proclaiming it to be a bug in the OS.

Incidentally, looking through the first 3 pages of results, most of
the users seem to be having problems entering the WEP/WPA/WPA2
encryption key. However, that has nothing to do with what you're
seeing.

[Jeff Liebermann]

On Mon, 11 Jun 2012 21:07:34 -0700, JC Dill <jcdill...@gmail.com>
wrote:

>On 11/06/12 11:23 AM, Jeff Liebermann wrote:
>> Like I mumbled, killing the auto-IP feature isn't going to do
>> anything. The network software assigns the 169.254.xxx.xxx address
>> only*after* DHCP fails to negotiate a proper IP address. If you turn
>> off auto-IP, all that will change is that you'll get a blank IP
>> address instead.
>
>It might pop-up a message if that happened. Instead it silently
>pretends it has established network connectivity. Until you actually
>try to use the network and find out that you don't have a working
>connection.

Yep. Windoze XP does the same thing. There's no connection progress
log output showing at which step it failed. Microsoft's attitude is
that it's too complicated for the average user to have this
information. Apple's is probably "You don't need to know".
Determining the point where it's failing is a chronic problem in the
wireless newsgroups and lists.

>> The problem is probably in the DHCP negotiation.
>
>The problem is DEFINITELY in the DHCP negotiation. I'm trying to figure
>out a way to keep it from quitting so fast, or to make it try again.

I wished I had an answer. You gave me a clue in that the
169.254.xxx.xxx address returns far too quickly when you retry. That
means something is not getting reset. You've already tried
enable/disable on the Airport connection icon. Try some of the
following and see if it recovers.

From the terminal window:

Turn the airport card off and on:
networksetup -setairportpower airport off
networksetup -setairportpower airport on

Disable an enable the wireless interface:
sudo ifconfig en1 down
sudo ifconfig en1 up

Flush DNS cache:
dscacheutil -flushcache

Force a DHCP renewal:
sudo ipconfig set en1 DHCP (renew lease)
ipconfig getifaddr en1 (check lease)

Clear ARP entry for router:
arp -a (lists arp table)
arp -d 192.168.1.1 (delete gateway IP)
ping 192.168.1.1 (reload gateway IP)
apr -a (check if it worked)
This one is fairly important because if the ARP table entry for your
previous wireless router connection just happens to have the same IP
address as the current wireless router, the IP stack is not smart
enough to delete the old entry, you will have connection problems.

You can also try to connect manually from the command line, in case
there's something broken in the GUI tools. However I doubt this will
do anything helpful:
<http://osxdaily.com/2011/04/12/connect-wireless-network-command-line/>

You can also set your laptop for a fixed IP address, gateway, and DNS
servers. This is risky because if you duplicate another users IP
address, both machines will have problems. You'll also need to know
the gateway IP address but that can be obtained by asking a user with
a working connections.

Incidentally, I tried all of these on my iMac G4

[Jeff Liebermann]

On Mon, 11 Jun 2012 21:55:29 -0700, Jeff Liebermann <je...@cruzio.com>
wrote:

>Turn the airport card off and on:
> networksetup -setairportpower airport off
> networksetup -setairportpower airport on

Typo error. It should be:

Turn the airport card off and on:

sudo networksetup -setairportpower off
sudo networksetup -setairportpower on

[Travis James]

On 6/11/2012 9:19 PM, Jeff Liebermann wrote:
> On Mon, 11 Jun 2012 21:03:58 -0700, JC Dill<jcdill...@gmail.com>
> wrote:
>
>> Please take a look at the apple website, using the link I posted at the
>> beginning of the thread:
>>
>> <http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>
>>
>> There are almost 24,000 different posts from people with this same
>> problem.
>
> Try putting a plus sign in front of the word "bug" on the Google
> search line. That makes the search require the word "bug" in the
> results. It goes from 9800 hits to zero. I got the same results with
> the word "problem".
>
> You're correct that many people are failing to get a DHCP assigned IP
> address, but none are proclaiming it to be a bug in the OS.
>
> Incidentally, looking through the first 3 pages of results, most of
> the users seem to be having problems entering the WEP/WPA/WPA2
> encryption key. However, that has nothing to do with what you're
> seeing.
>

Methinks you're going to get YELLED AT IN ALL CAPS for some reason. :-)

[bi...@mix.com]

Jeff Liebermann <je...@cruzio.com> writes:

> Maybe seeing what happens during the DHCP negotiations will help:
> <http://www.sustworks.com/site/prod_ipmx_overview.html>
> 21 day free trial. Try the DHCP test at home and at the coffee shop.
> Compare results. I'm stuck on 10.5 so I can't try it.

This version runs on 10.5 -

ftp://sustworks.com/IPNetMonitorX_2.5c2.dmg

and can do the DHCP test (click on the DHCP Lease button in its
Launcher window, then select DCHP Test).

Thanks!

[JC Dill]

On 11/06/12 9:19 PM, Jeff Liebermann wrote:
> On Mon, 11 Jun 2012 21:03:58 -0700, JC Dill<jcdill...@gmail.com>
> wrote:
>
>> Please take a look at the apple website, using the link I posted at the
>> beginning of the thread:
>>
>> <http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>
>>
>> There are almost 24,000 different posts from people with this same
>> problem.
>
> Try putting a plus sign in front of the word "bug" on the Google

Plus signs don't work that way on Google anymore, not since they
introduced G+. Now you have to enclose words in quotes to require them.

<https://www.google.com/search?q=site:apple.com+%22self+assigned+ip+address%22+%22bug%22>

> search line. That makes the search require the word "bug" in the
> results. It goes from 9800 hits to zero. I got the same results with
> the word "problem".

<https://www.google.com/search?q=site:apple.com+%22self+assigned+ip+address%22+%22problem%22>


About 43,000 results.

> You're correct that many people are failing to get a DHCP assigned IP
> address, but none are proclaiming it to be a bug in the OS.
>
> Incidentally, looking through the first 3 pages of results, most of
> the users seem to be having problems entering the WEP/WPA/WPA2
> encryption key. However, that has nothing to do with what you're
> seeing.

If you had simply looked at the results from the link I first posted,
you would see that's not the case at all. There are thousands upon
thousands of reports of problems from this issue.

jc

[Jeff Liebermann]

On Tue, 12 Jun 2012 06:39:20 -0700, JC Dill <jcdill...@gmail.com>
wrote:

>Plus signs don't work that way on Google anymore, not since they
>introduced G+. Now you have to enclose words in quotes to require them.

Oops. I didn't know that. Thanks.

>About 43,000 results.

Ok. That's plenty. I went through some of the threads on
discussions.apple.com and found quite a few "me too" replies with the
same problem. I stand corrected. It's a real problem.

>If you had simply looked at the results from the link I first posted,
>you would see that's not the case at all. There are thousands upon
>thousands of reports of problems from this issue.

Done. You're right. Some of the solutions are not exactly elegant.
Some are wrong, such as clearing the PRAM (NVRAM) which does not store
network settings. This is beginning to feel like quicksand.

I did some digging in:
/Library/Preferences/SystemConfiguration
looking at:
com.apple.network.identification.plist
com.apple.airport.preferences.plist
Reading the XML, it looks ok. My guess(tm) is that if there's any
failure to connect, it's buried in one of these config files. I can
delete any section using:
system Prefs -> Network -> Airport -> Advanced -> Airport
and deleting the Network Name (SSID) in question. That should
effectively start the connect ceremony over from scratch. If you get
stuck with 169.254.xxx.xxx on a network that previously worked, try
deleting it and starting over.

Drivel: The tiny Apple "cube" USB power supply for my iPhone just
died without reason. It's sealed, so no repair or autopsy. I really
don't like unrepairable Apple products.

[Jeff Liebermann]

On Mon, 11 Jun 2012 22:18:18 -0700, Travis James
<travis...@gmail.com> wrote:

>Methinks you're going to get YELLED AT IN ALL CAPS for some reason. :-)

No problem:
$ cat ALL_CAPS_YELLING_MESSAGE | dd conv=lcase
Yelling fixed.

[Jeff Liebermann]

On Tue, 12 Jun 2012 05:47:35 +0000 (UTC), bi...@MIX.COM wrote:

>Jeff Liebermann <je...@cruzio.com> writes:
>
>> Maybe seeing what happens during the DHCP negotiations will help:
>> <http://www.sustworks.com/site/prod_ipmx_overview.html>
>> 21 day free trial. Try the DHCP test at home and at the coffee shop.
>> Compare results. I'm stuck on 10.5 so I can't try it.
>
>This version runs on 10.5 -
>
>ftp://sustworks.com/IPNetMonitorX_2.5c2.dmg
>
>and can do the DHCP test (click on the DHCP Lease button in its
>Launcher window, then select DCHP Test).

Thanks. It works on 10.5.8. The verbose logs in:
/Libarary/Logs/IPNetMonitorX/
are not very verbose and do not show the steps in the DHCP
negotiation. I'll play with it some more when I have time.

[JC Dill]

On 12/06/12 8:09 AM, Jeff Liebermann wrote:
> On Tue, 12 Jun 2012 06:39:20 -0700, JC Dill<jcdill...@gmail.com>
> wrote:
>
>> Plus signs don't work that way on Google anymore, not since they
>> introduced G+. Now you have to enclose words in quotes to require them.
>
> Oops. I didn't know that. Thanks.

AND, it's a REAL PITA to have to type quote marks on a smartphone.
Instead of a single plus (3 keystrokes, one to change to the symbols
keyboard, one to select the plus, one to change back to the alphabet
keyboard) it's now 6 keystrokes (all of the above, twice, to select the
2 quote symbols).

I wish they would stop trying to "improve" things. I remember back when
Google actually did what you told it to do, if you typed a series of
words into the search box it actually returned pages WITH THOSE WORDS ON
IT, instead of thinking it was smarter than the user and guessing which
words really mattered, and which ones it could ignore.

I wish there was a user setting that said simply "always treat all words
entered as required terms".

There's a web workaround by using finderr.com to enter your search
terms. Finderr then encases each term in quotes for you before sending
the search query on to Google. But it adds time to get the results back
from Google, and of course now you are revealing your search terms to
yet-another-website that may archive the results to later be used for
nefarious purposes.

>> About 43,000 results.
>
> Ok. That's plenty. I went through some of the threads on
> discussions.apple.com and found quite a few "me too" replies with the
> same problem. I stand corrected. It's a real problem.
>
>> If you had simply looked at the results from the link I first posted,
>> you would see that's not the case at all. There are thousands upon
>> thousands of reports of problems from this issue.
>
> Done. You're right. Some of the solutions are not exactly elegant.
> Some are wrong, such as clearing the PRAM (NVRAM) which does not store
> network settings. This is beginning to feel like quicksand.

Exactly. :-(

> I did some digging in:
> /Library/Preferences/SystemConfiguration
> looking at:
> com.apple.network.identification.plist
> com.apple.airport.preferences.plist
> Reading the XML, it looks ok. My guess(tm) is that if there's any
> failure to connect, it's buried in one of these config files. I can
> delete any section using:
> system Prefs -> Network -> Airport -> Advanced -> Airport
> and deleting the Network Name (SSID) in question. That should
> effectively start the connect ceremony over from scratch. If you get
> stuck with 169.254.xxx.xxx on a network that previously worked, try
> deleting it and starting over.

The most recent incident happened at a coffee shop in SF that I'd never
visited before. The previous incident happened at a different coffee
shop (in Gallup NM) that I'd never visited before. The incident prior
to that was at the Day's Inn in Chambers AZ which I had never visited
before.

So that solution doesn't help much.

I'm pretty sure there's a bug somewhere in the DHCP process, and if it
could be forced to wait longer or retry before dumping into the
self-assigned process, it would solve the problem.

> Drivel: The tiny Apple "cube" USB power supply for my iPhone just
> died without reason. It's sealed, so no repair or autopsy. I really
> don't like unrepairable Apple products.

Can't you break a seam seal to open it? I did that to repair a laptop
charger brick one time, resealed it with electrical tape...

My iDevice cubes are just 120v-5v USB power sources. I can unplug the
usb cord and plug it into a different usb port anywhere.

jc

[bi...@mix.com]

Jeff Liebermann <je...@cruzio.com> writes:

> I did some digging in:
> /Library/Preferences/SystemConfiguration
> looking at:
> com.apple.network.identification.plist
> com.apple.airport.preferences.plist

The latter used to have a parameter called Join Mode, where the
choices were automatic, prefered, ranked, recent, and strongest
(and none), but it has vanished in OS 10.5...

> Drivel: The tiny Apple "cube" USB power supply for my iPhone just
> died without reason. It's sealed, so no repair or autopsy. I really
> don't like unrepairable Apple products.

You can get a new one here for just US$10.88 (sans cables) -

http://eshop.macsales.com/item/Apple/MC359LLANB/

I'd save the tiny slip-in AC plug from the old one as they
wear out if the blades are opened and closed a lot.

[Marcus Allen]

On Tue, 12 Jun 2012 08:42:04 -0700, JC Dill <jcdill...@gmail.com>

wrote:

>On 12/06/12 8:09 AM, Jeff Liebermann wrote:
>> On Tue, 12 Jun 2012 06:39:20 -0700, JC Dill<jcdill...@gmail.com>
>> wrote:
>>
>>> Plus signs don't work that way on Google anymore, not since they
>>> introduced G+. Now you have to enclose words in quotes to require them.
>>
>> Oops. I didn't know that. Thanks.
>
>AND, it's a REAL PITA to have to type quote marks on a smartphone.
>Instead of a single plus (3 keystrokes, one to change to the symbols
>keyboard, one to select the plus, one to change back to the alphabet
>keyboard) it's now 6 keystrokes (all of the above, twice, to select the
>2 quote symbols).
>
>I wish they would stop trying to "improve" things. I remember back when
>Google actually did what you told it to do, if you typed a series of
>words into the search box it actually returned pages WITH THOSE WORDS ON
>IT, instead of thinking it was smarter than the user and guessing which
>words really mattered, and which ones it could ignore.
>
>I wish there was a user setting that said simply "always treat all words
>entered as required terms".

Does Google's advanced search also suffer from all of that nonsense?

<http://www.google.com/advanced_search>

[bi...@mix.com]

JC Dill <jcdill...@gmail.com> writes:

> I'm pretty sure there's a bug somewhere in the DHCP process, and if it
> could be forced to wait longer or retry before dumping into the
> self-assigned process, it would solve the problem.

OK, take a look here, for 10.5 and later -

/System/Library/SystemConfiguration/IPConfiguation.bundle/Contents/Resources/IPConfiguration.xml

or for 10.4 and earlier -

/System/Library/SystemConfiguration/IPConfiguration.bundle/Resources/IPConfiguration.bundle

Lots of stuff to play with. If/when I have more time I'll try to track
down what the numbers in the parameter list do - unless someone beats me
to it (please do).

To be sure, once you've navigated to the SystemConfiguration folder, you'll
have to control or right click on IPConfiguation.bundle to proceed into it.
Or just do this from the command line (Terminal emulator), which will likely
be easier, as you'll need privileges to edit the config file.

At the risk of getting yelled at again, be sure to make a backup copy first.
Heh. As well, this stuff may be cached somewhere, and that might need to be
flushed for any changes to take effect.

[bi...@mix.com]

> or for 10.4 and earlier -
>
> /System/Library/SystemConfiguration/IPConfiguration.bundle/Resources/IPConfiguration.bundle

^^^^^^^
Opps, make this .xml

[TJ Merritt]

On Jun 11, 9:07 pm, JC Dill <jcdill.li...@gmail.com> wrote:
> The problem is DEFINITELY in the DHCP negotiation. I'm trying to figure
> out a way to keep it from quitting so fast, or to make it try again.

The way the process works is that a lladdr is assigned to the
interface and a DHCP address request is sent when the interface comes
up. The lladdr will stay until a DHCP address is successfully
negotiated. The DHCP address request is retried if it fails. The
lladdr is useful for Bonjour, even if a DHCP address can not be
acquired, to communicate with other machines on the local network.
Don't expect that this behavior will be going away. Windows does the
same things, so it isn't Mac specific. If you install a network
analyzer such as wireshark, you can see that the Mac is sending out
DHCP requests and that the router is not positively responding to
them.

The DHCP protocol has options that can be included with the DHCP
request, these should not prevent a device from getting an address,
but your mileage may vary depending upon the router in use. Different
versions of Mac OS and Windows set different options, so there may be
a specific option that causes a problem. The only machine that I have
DHCP problems with at home is a Windows XP box that I no longer use.
On the road I have had the "can't get an address problem", but it
always traces back to the router. If my Mac can't get an address,
then my Android phone won't be able to get one either.

The typical router issue is a DHCP server that only gives out 250
addresses (or less) and uses a lease time in days. After all of the
leases have been given out, nobody can get an address, until the
oldest one expires. Rebooting the router solves the problem because
the lease table goes back to empty. This is pretty much expected
behaviour in cheap ass public wifi environments such as cafe's, etc.
I found that cafe's with this problem are used to customers asking
them to reset their router so that customers can get on. The problem
is pretty easy to solve if you are able to shorten the lease time on
the routers DHCP server. Ten minutes is a good choice for puiblic
WiFi environments.

[JC Dill]

Yes. It doesn't matter which search form you use, Google now treats all
the words you enter as "optional" and presents you with what they think
is the best result, even if some of the terms you entered are not
present on the results page. To force Google to actually include all
the words you entered, you must enclose each one in quotes.

jc

[JC Dill]

On 12/06/12 3:39 PM, TJ Merritt wrote:
> On Jun 11, 9:07 pm, JC Dill<jcdill.li...@gmail.com> wrote:
>> The problem is DEFINITELY in the DHCP negotiation. I'm trying to figure
>> out a way to keep it from quitting so fast, or to make it try again.
>
> The way the process works is that a lladdr is assigned to the
> interface and a DHCP address request is sent when the interface comes
> up. The lladdr will stay until a DHCP address is successfully
> negotiated. The DHCP address request is retried if it fails. The
> lladdr is useful for Bonjour, even if a DHCP address can not be
> acquired, to communicate with other machines on the local network.
> Don't expect that this behavior will be going away. Windows does the
> same things, so it isn't Mac specific. If you install a network
> analyzer such as wireshark,

I have Wireshark installed. Can you give me step-by-step instructions
on what to do to capture the info, and then print it out to share with
you and others?

When I launch Wireshark, it launches x11 which gives me an xterm window
for bash 3.2 in my home directory. Is there supposed to be an x11 gui
for Wireshark?

Oh... nevermind the above, Wireshark finally opened its GUI. (Took
about 3 minutes to bring up the Wireshark GUI.)

OK, now the stupid part. The GUI has a link for instructions, which
then take you to a Wireshark wiki page. This is, of course, totally
useless if you are trying to debug a network connection which is NOT
WORKING, as you can't get to the Wiki to get the instructions on how to
use Wireshark.

(This is one of the biggest problems with Open Sores (thanks to
UserFriendly for that) software, that the developers don't think about
real user problems, if it "works for them" they figure it's good enough.)

I'm trying to print the pages to PDF so I will have the info at hand,
and of course now the process is hanging with the beachball of death. :-(

OK, PDFs saved. I hope I have all I need to get Wireshark to actually
capture when the time comes.

you can see that the Mac is sending out
> DHCP requests and that the router is not positively responding to
> them.

Theoretically. As I said, I've had a refresh/renew "finish" in a small
fraction of the time it takes when the process works properly.

Testing....

At the Starbucks I'm at now, it takes apx 2-3 seconds to renew the DHCP
lease and give me a new (or the same old) IP address. But when the DHCP
process is borked and keeps giving me a self-assigned 169 address, a
refresh/renew will often (not always, but often) finish in a flash, in
less than 1/2 second. (Possibly as fast as .1 second, I'll see if I can
time it the next time it happens.)

IMHO, this is a clear sign that something is wrong on the Mac end, that
it isn't waiting to get the DHCP answer from the router.

> The DHCP protocol has options that can be included with the DHCP
> request, these should not prevent a device from getting an address,
> but your mileage may vary depending upon the router in use. Different
> versions of Mac OS and Windows set different options, so there may be
> a specific option that causes a problem. The only machine that I have
> DHCP problems with at home is a Windows XP box that I no longer use.
> On the road I have had the "can't get an address problem", but it
> always traces back to the router. If my Mac can't get an address,
> then my Android phone won't be able to get one either.
>
> The typical router issue is a DHCP server that only gives out 250
> addresses (or less) and uses a lease time in days. After all of the
> leases have been given out, nobody can get an address, until the
> oldest one expires. Rebooting the router solves the problem because
> the lease table goes back to empty. This is pretty much expected
> behaviour in cheap ass public wifi environments such as cafe's, etc.
> I found that cafe's with this problem are used to customers asking
> them to reset their router so that customers can get on. The problem
> is pretty easy to solve if you are able to shorten the lease time on
> the routers DHCP server. Ten minutes is a good choice for puiblic
> WiFi environments.

I'm aware of the "typical router" issues you list above. This 169
problem is unique to Macs. I can go into a coffee shop where everyone
else (using Windows computers) gets an IP no problem, but I get a 169 IP
address. Clearly, the problem isn't the router if it's happily giving
out IP addresses to other computers.

When the router isn't working for anyone, it's usually easy to get them
to reboot the router, and then it will work for everyone. The problem I
have is when it's working for everyone else - in that situation they are
often loathe to reboot just because *I* can't get an IP address. And as
you can see in the discussions on the Apple forums, this problem also
occurs for many people in their home environments, where there aren't
dozens/hundreds of different machines connecting over time and using up
all the DHCP IPs.

jc

[bi...@mix.com]

> I'll try to track down what the numbers in the parameter list do -

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml

[NoOp]

On 06/11/2012 11:23 AM, Jeff Liebermann wrote:
> On Sun, 10 Jun 2012 23:30:10 -0700, JC Dill <jcdill...@gmail.com>
> wrote:
>
>>It's clearly not the router's fault if most of the laptops can connect
>>fine and everyone who is having problems has a Mac.

Maybe/maybe not? It may depend upon the router firmware/software. Simply
because a WinPC connects OK doesn't necessarily mean the problem is not
a router issue. But you knew that alread... right? :-)

Linux kernel developers have had considerable issues with hardware &
firmware simply due to the OEM tailoring to Microsoft specs only.
Basically that means that the product is supplied to MSoft specs only,
and such specs may purposely ignore the fact that MSoft does it one way,
the rest of the world does it another.
https://tools.ietf.org/html/rfc4795 is a good example.

I'm not attempting to bash MSoft or the OEM here, just pointing out that
it's not a forgone conclusive (or even proper) given that the router is
not at fault.

Umm... you do troubleshoot USSC issues etc., right? Quite often
university/college students run into issues due to misconfiguration
issues - their peers using Windows can connect, others (MAC primarily)
cannot. You've troubleshot similar in this newsgroup - check the archives.

You may be right, but I wouldn't make such a broad sweeping statement -
ever.

>
> Ok, I'm convinced.

I'm not.

The existing standard was primarily authored by Apple (S. Cheshire)[1]:
https://tools.ietf.org/html/rfc4795
[Dynamic Configuration of IPv4 Link-Local Addresses]
Zeroconf was
[1] http://www.stuartcheshire.org/
<http://web.archive.org/web/20020930145225/http://www.zeroconf.org/>

Seems odd to me that the company that co-authored the LLA rfc is that
far out of wack.

https://developer.apple.com/library/mac/#qa/qa1357/_index.html
[Q: How can I configure my computer to communicate with devices which
use link-local IP addresses when my computer is using a routable IP
address? How can I configure my computer to communicate with devices
which use routable IP addresses when my computer is using a link-local
IP address?]

and even expanding to linux:
<http://manpages.ubuntu.com/manpages/precise/man8/avahi-autoipd.8.html>
<http://avahi.org/wiki/AvahiAutoipd#Routes>
(Note: a Redhat patch changed this to metric 1000. see:
<https://bugzilla.redhat.com/show_bug.cgi?id=239609#c2>)

>
> Maybe seeing what happens during the DHCP negotiations will help:

And also an overview of what may be happening:

<https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NetServices/Introduction.html>

> <http://www.sustworks.com/site/prod_ipmx_overview.html>
> 21 day free trial. Try the DHCP test at home and at the coffee shop.
> Compare results. I'm stuck on 10.5 so I can't try it.

Perhaps using the standard troubleshooting procedures may work?

I do not know much of anything Apple beyond duckduckgo/google:
<http://osxdaily.com/2009/09/01/how-i-fixed-my-dropping-wireless-airport-connection-problem-in-snow-leopard/>

But linux & FreeBSD are pretty close to each other regarding networking
(IIRC), so troubleshooting should be similar. Quite often other OS
troubleshooting guides may be of use:
<https://help.ubuntu.com/10.04/internet/C/troubleshooting-wireless.html>
<https://help.ubuntu.com/community/WifiDocs>
I reckon that Apple have something similar.

But first I'd check the simple bits:

o Do I have my network manager (whatever it may be) configured properly
for roaming?
- Example: I may have IPv6 set up for my net config on my network & have
something like 'Require IPv6 addressing for this connection to complete'
- using DHCP. If the router + ISP doesn't support IPv6 outside of Terado
etc., then the connection with spin and spin and fail.
o Quite often 'home' users have their network manager perfectly set for,
well, home. But when they venture out some, even many, connections may
work, but some may not.
- Is my NM interface set for matching Wifi security?
- Do I need to check at the front desk to get a password and setting
information for my connection?

>
> The trick will be to find out at what point during the negotiation
> does it fail. Note that auto-IP will kick in no matter where it
> fails, so you can't use it for diagnostics. A single connection
> progress report on Windoze XP can end up 200 lines long, so it's
> obviously not a simple exercise.

My approach would be to get standard information at the time of the
failure. Simple first:

$ arp
$ netstat -rn
$ ifconfig
$ cat /etc/resolv.conf
$ iwconfig
$ iwlist scan
$ ping
etc., etc.

It's (again IMO) highly unlikely that a user is going to set in a coffee
shop and try wireshark et al. I'd rather get information regarding the
users settings for NM, wireless drivers,

IMO 196.254.x.x isn't a boogyman. It's well defined in
https://tools.ietf.org/html/rfc3927
and
https://tools.ietf.org/html/rfc5735
...

[bi...@mix.com]

JC Dill <jcdill...@gmail.com> writes:

> At the Starbucks I'm at now, it takes apx 2-3 seconds to renew the DHCP
> lease and give me a new (or the same old) IP address.

You can see the exact timing (to the millisecond) using the tool Jeff L.
suggested -

http://MIX.COM/DHCP_Test.jpeg

You can also give it a comma-delimited list of options from your system's
DHCPRequestedParameterList, see what happens, then dump them one by one
until you discover what works.

I don't have any convenient way to generate a failure, but I suspect the
error reporting will be sufficient.

[Brad Allen]

In article <t8ket7pduf4j4injp...@4ax.com>,

Jeff Liebermann <je...@cruzio.com> wrote:

" I did some digging in:
" /Library/Preferences/SystemConfiguration
" looking at:
" com.apple.network.identification.plist
" com.apple.airport.preferences.plist
" Reading the XML, it looks ok. My guess(tm) is that if there's any
" failure to connect, it's buried in one of these config files. I can
" delete any section using:
" system Prefs -> Network -> Airport -> Advanced -> Airport
" and deleting the Network Name (SSID) in question. That should
" effectively start the connect ceremony over from scratch. If you get
" stuck with 169.254.xxx.xxx on a network that previously worked, try
" deleting it and starting over.

I get JC Dill's problem on my Linux computers all the time. Which
Linux computers, you ask? Why, most often, my Android OS pocket
radio, entitled "Google Nexus One". Well, inside the touch screen
interface is a Settings, Network, Wifi, and I go to the SSID in
question, and delete it, and this is enough to allow it to retry.
Sometimes this retry is enough, and sometimes not. But it is the same
principle as the Mac OS X that JeffL just described above, and with
the same result. So this makes sense.

Other things I have to do:

* Enter the SSID manually (arg). Rarely helps, but has helped.

* Restart DHCP daemon. Has worked a few times. Yes, requires shell.

* Add IP# manually, exactly as JeffL already stated. Trick, as he said,
is guessing an IP# that the router will accept and isn't in use.
Often works, but is a nuisance to do. Must also undo afterwards.

Same principles as Mac OS X. (Wildly different interface.)

[Brad Allen]

In article <jr7o0a$tug$1...@speranza.aioe.org>,

JC Dill <jcdill...@gmail.com> wrote:

" I wish they would stop trying to "improve" things. I remember back
" when Google actually did what you told it to do, if you typed a
" series of words into the search box it actually returned pages WITH
" THOSE WORDS ON IT, instead of thinking it was smarter than the user
" and guessing which words really mattered, and which ones it could
" ignore.

I knew Google was getting worse. I've been having more and more
difficulty getting it to find stuff. Often I have to find something
tangental but which points to what I want, whereas it used to just
find what I wanted. My searches have therefore become extremely
unlike what I'm looking for.

" There's a web workaround by using finderr.com to enter your search

s/b finderr.org

Awesome!!!

[JC Dill]

On 13/06/12 12:55 PM, Brad Allen wrote:
> " There's a web workaround by using finderr.com to enter your search
>
> s/b finderr.org

oops! I use the browser search tool so I don't actually see the domain
name, it loads the finderr webpage briefly before handing the search
query off to Google, en-quoted.

jc

[Jeff Liebermann]

On Wed, 13 Jun 2012 15:38:29 -0700, JC Dill <jcdill...@gmail.com>
wrote:

I've been using Blekko lately:
<http://www.blekko.com>
<https://addons.mozilla.org/en-US/firefox/addon/blekko-search-plugin/>
I'm still learning how to use and abuse the advanced features:
<http://help.blekko.com/index.php/advanced-search-features/>
<http://www.pcworld.com/article/209392/blekko_search_engine_slashes_through_the_web.html>
The real power is behind the slashtags:
<http://blekko.com/tag/show#tab3>
For example, if I inscribe:
ipad 3 /reviews
I get reviews, not advertisements, spam, news, press releases, etc.

They seem to have their own crawler, which means they don't forward
searches to Google. It is also possible to look at the logic used,
but you need to have a login account to do that:
<http://help.blekko.com/index.php/what-information-is-available-on-the-seo-pages/>
Yandex just poured $30 million into the company. I haven't figured
out if it's a Russian, US, or both company:
<http://www.pcworld.com/article/240905/search_engine_blekko_hauls_in_15m_russian_investment.html>

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558
# http://802.11junk.com je...@cruzio.com
# http://www.LearnByDestroying.com AE6KS

[NoOp]

On 06/13/2012 05:12 PM, Jeff Liebermann wrote:
> On Wed, 13 Jun 2012 15:38:29 -0700, JC Dill <jcdill...@gmail.com>
> wrote:
>
>>On 13/06/12 12:55 PM, Brad Allen wrote:
>>> " There's a web workaround by using finderr.com to enter your search
>>>
>>> s/b finderr.org
>>
>>oops! I use the browser search tool so I don't actually see the domain
>>name, it loads the finderr webpage briefly before handing the search
>>query off to Google, en-quoted.
>
> I've been using Blekko lately:
> <http://www.blekko.com>

<https://blekko.com/about>
"Quality vs Quantity: blekko biases towards quality sites. We do not
attempt to gather all of the world's information. We purposefully bias
our index away from sites with low quality content."

So it's "purposefully bias"ed?

Have you looked at
https://duckduckgo.com
https://duckduckgo.com/about.html
(yes I know it's a weird name)
https://duckduckgo.com/privacy.html
vs
https://blekko.com/about/privacy-policy

and see:
http://donttrack.us/ (duckduckgo.com link)

And if DDG can't find what you are looking for, it will provide a jump
link to Google/Bing/Other.

https://duckduckgo.com/?q=blekko
https://blekko.com/ws/?q=blekko
<http://www.bing.com/search?q=blekko&qs=n&form=QBLH&pq=blekko&sc=8-0&sp=-1&sk=>

> <https://addons.mozilla.org/en-US/firefox/addon/blekko-search-plugin/>
> I'm still learning how to use and abuse the advanced features:
> <http://help.blekko.com/index.php/advanced-search-features/>
> <http://www.pcworld.com/article/209392/blekko_search_engine_slashes_through_the_web.html>
> The real power is behind the slashtags:
> <http://blekko.com/tag/show#tab3>
> For example, if I inscribe:
> ipad 3 /reviews
> I get reviews, not advertisements, spam, news, press releases, etc.
>
> They seem to have their own crawler, which means they don't forward
> searches to Google. It is also possible to look at the logic used,

You can do the same with DDG. But I turn off cookies, java, and flash
with any search engine. I reckon that I don't appreciate the "added
features" like geotracking, profile setting, et al.

> but you need to have a login account to do that:
> <http://help.blekko.com/index.php/what-information-is-available-on-the-seo-pages/>
> Yandex just poured $30 million into the company.

Hmmm..
http://blog.blekko.com/2011/09/29/618/
I wouldn't call Sept 2011 "just". September, October, November, January,
February, March, April, May, June... Eight months is a lifetime in some
tech circles.

I haven't figured
> out if it's a Russian, US, or both company:
> <http://www.pcworld.com/article/240905/search_engine_blekko_hauls_in_15m_russian_investment.html>
>

See above.

You might also find these of interest:

<https://duckduckgo.com/?q=%22blekko+toolbar%22>

<http://help.blekko.com/index.php/i-downloaded-the-toolbar-but-now-i-don%E2%80%99t-want-it-how-do-i-get-rid-of-it/>

<https://blekko.com/ws/%22blekko+toolbar%22>
Nothing on that first page on how to remove the toolbar. Let's try Google:
<https://encrypted.google.com/#hl=en&output=search&sclient=psy-ab&q=%22blekko+toolbar%22&oq=%22blekko+toolbar%22&aq=f&aqi=&aql=&gs_l=hp.3...1902.1902.0.2007.1.1.0.0.0.0.0.0..0.0...0.0.Yh2grBhsvME&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=6ff46385ca0207ea&biw=1280&bih=736>
Second link:
<http://help.blekko.com/index.php/category/toolbar/>
<http://www.bing.com/search?q=%22blekko+toolbar%22&qs=n&form=QBLH&pq=%22blekko+toolbar%22&sc=1-16&sp=-1&sk=>
Second link:
<http://help.blekko.com/index.php/category/toolbar/>

Biased indeed :-)

To be fair:
<https://duckduckgo.com/?q=%22duckduckgo+toolbar%22>
<https://blekko.com/ws/%22duckduckgo+toolbar%22>
<https://encrypted.google.com/#hl=en&output=search&sclient=psy-ab&q=%22duckduckgo+toolbar%22&oq=%22duckduckgo+toolbar%22&aq=f&aqi=&aql=&gs_l=hp.4...2241.2241.0.2944.1.1.0.0.0.0.0.0..0.0...0.0.OCYQM_WWdlU&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=20f5c44bf144d123&biw=1280&bih=736>
<http://www.bing.com/search?q=%22duckduckgo+toolbar%22&qs=n&form=QBLH&pq=%22duckduckgo+toolbar%22&sc=1-20&sp=-1&sk=>

BTW: there is an addon for a DDG toolbar:
https://addons.mozilla.org/en-US/seamonkey/addon/duckduckgo-ssl/

[Kevin McMurtrie]

In article <jr3kdj$3qt$1...@speranza.aioe.org>,
JC Dill <jcdill...@gmail.com> wrote:

> I run into this periodically, often when traveling and trying to use a
> coffee shop or hotel WiFi network. There's a long standing bug in OS X
> where the DHCP handshake doesn't work right, and Apple's "solution" is
> to give the computer a self-assigned IP starting with 169. which is a
> non-routable IP address. This is a completely USELESS "solution".
> People have been complaining about this in Apple forums for YEARS:
>
> <http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+as
> signed+ip+address%22+bug>
>
> Sometimes rebooting the router helps. Sometimes it does not help. When
> I am at a coffee shop or hotel I can't just be demanding they reboot
> their router because my computer is stupid and can't properly handshake
> with their router.
>
> I'm hoping someone here has figured out a work-around, some way to tell
> the apple TCP/IP service to not use this "feature" so that it WAITS for
> the DHCP handshake to finish and receive a routable IP address from the
> router.
>
> jc

Network preferences -> Advanced -> Renew DHCP Lease

It could be worse. Both of my printers turn off a network port when
there is a problem. The Ethernet cable isn't plugged in so that
interface turns off. The WiFi runs just fine until one day there's a
WPA2 handshake error, then the WiFi port turns off. Now it's a very
large paperweight until going through the secret button presses for a
factory reset.
--
I will not see posts from Google because I must filter them as spam

[Peter Lawrence]

On 6/11/12 9:03 PM, JC Dill wrote:
>
> Please take a look at the apple website, using the link I posted at the
> beginning of the thread:
>
> <http://www.google.com/search?client=safari&rls=en&q=site:apple.com+%22self+assigned+ip+address%22+bug>
>
>
> There are almost 24,000 different posts from people with this same problem.

> The OS version and hardware version does not matter. People have been
> having this problem for years on many different OSs, many different
> computers (laptop and desktop).


I'll chime in.

I used to occasionally have this problem with my old iBook G4 and and a
couple of my desktop Macs at home. The thing is, my other Macs, even at
home, didn't have that problem. The difference between the various Macs was
the 3rd party software installed on them. While they shared some of the
same apps, each often had other apps, or different versions of a particular app.

My guess was the problem that my three Macs (one notebook and two desktops)
suffered from was the result of some third-party app(s) not playing nice
with the Mac OS since my other Macs would never have the same IP problem on
my home networks.

Nowadays of the coffee shops I visit, at least 40% of the laptops in use are
Macs and they all seem to be happily connected to the internet. I doubt
that you are that often the *only* Macintosh user at the coffee shop. So
when you experience this problem again see if the other Mac users are using
(or trying to use) the same WiFi network. If they are successfully
connected to the network, then it's something specific to your Mac that's
the problem and not necessarily the Mac OS. Again, my suspicion is that
some third-party app is the culprit.


- Peter

[JC Dill]

On 15/06/12 9:08 PM, Kevin McMurtrie wrote:

>
> Network preferences -> Advanced -> Renew DHCP Lease

Does not work. The renew process "ends" far too fast, it's clear that
the Mac is not properly talking to the router and waiting for a DHCP reply.

I was just having coffee with Jeff at Coffee 9 in Ben Lomond, and Jeff
got to see this problem in person. He couldn't fix it. He knows the
owners of this cafe and could reboot the router, which he did, then the
laptop was able to connect. But this is not an option at most places,
and it's not a fair solution when others who are using the wifi have no
problem getting a routable IP address.


jc

[Peter Lawrence]

But a relevant question is: do all the MacBooks users that are trying to use
the same WiFi that you are trying to connect to are having the same problem
as you?

If not, why not?

If the majority of Mac users are not having any problems connecting, but
only a subset of Mac users are, then it might be something other than the
Mac OS. As I mentioned in another post, I've had this problem that you've
described on three of my Macintosh computers, but not the rest. The other
ones don't have this problem at all.

The only difference between the my Macs (besides being different Mac models)
that have the problem versus those that don't is the third-party software
that's installed.

When you're having problems connecting to the WiFi, launch the Mac's
"Activity Monitor" app to see what other processes are running. Some
third-party software, like the EasyShare app from Kodak likes to add
background processes at startup. These type of processes may be interfering
with your Mac's ability to connect to a WiFi network.


- Peter

[David Kaye]

"Peter Lawrence" <humm...@aol.com> wrote

> The only difference between the my Macs (besides being different Mac
> models) that have the problem versus those that don't is the third-party
> software that's installed.

...or perhaps 3rd party viruses. But, I'd be more inclined to suspect that
the wi-fi unit within the computer is at fault and that it's part of a bad
run, given that other users across the world are also having the problem.

Has this computer been tested with a direct ethernet connection? Does it
grab DHCP okay that way? If so, I'd say it's the wireless unit itself.

[Peter Lawrence]

On 6/16/12 2:13 PM, David Kaye wrote:
> "Peter Lawrence" <humm...@aol.com> wrote
>>
>> The only difference between the my Macs (besides being different Mac
>> models) that have the problem versus those that don't is the third-party
>> software that's installed.
>
> ...or perhaps 3rd party viruses. But, I'd be more inclined to suspect that
> the wi-fi unit within the computer is at fault and that it's part of a bad
> run, given that other users across the world are also having the problem.

Possibly. The key is that not all Mac computers have this problem. I think
the majority don't. But many do. So why does some Macintoshes exhibit this
behavior while others don't.

That's the key to finding the solution to this bug.


- Peter

[John Higdon]

In article <jrj7g5$dt8$1...@dont-email.me>,

Peter Lawrence <humm...@aol.com> wrote:

> Possibly. The key is that not all Mac computers have this problem. I think
> the majority don't. But many do. So why does some Macintoshes exhibit this
> behavior while others don't.
>
> That's the key to finding the solution to this bug.

My Mac has done this exactly once. The cause was my DHCP server (runs on
a Linux host) that had run out of assignable addresses. When I increased
the pool by 150%, the problem went away, never to return.

--
John Higdon
+1 775 253-3838

[David Kaye]

"Peter Lawrence" <humm...@aol.com> wrote

> Possibly. The key is that not all Mac computers have this problem. I
> think the majority don't. But many do. So why does some Macintoshes
> exhibit this behavior while others don't.

I'm opting for the wi-fi hardware problem rather than malware. Why some
Macs and not others? It's common for all computer manufacturers to switch
components in mid-run, which is why some companies have model sub-numbering
schemes.

But many models of computers aren't differentiated, which is why you can
look up, say, drivers for a Dell laptop and see drivers for 6 or 8 different
video units, even though the video is supposedly integrated within the
motherboard. I run into this stuff all the time when trying to install
drivers when all I have is the model number and no OEM disk.

If it's not a configuration or malware problem, I strongly suggest it's a
wi-fi unit problem. One option might be to get a wi-fi USB stick and try
that to see if it works. I'll bet a quarter that it'll work.

[David Kaye]

"David Kaye" <sfdavi...@yahoo.com> wrote

> If it's not a configuration or malware problem, I strongly suggest it's a
> wi-fi unit problem. One option might be to get a wi-fi USB stick and try
> that to see if it works. I'll bet a quarter that it'll work.

This assumes, of course that it's not the DHCP pool, but I believe the
original poster discounted this already. Plugging directly into the router
from that computer should answer that question easily.

[Marcus Allen]

On Sun, 17 Jun 2012 00:46:49 -0700, "David Kaye"
<sfdavi...@yahoo.com> wrote:

>"David Kaye" <sfdavi...@yahoo.com> wrote
>
>> If it's not a configuration or malware problem, I strongly suggest it's a
>> wi-fi unit problem. One option might be to get a wi-fi USB stick and try
>> that to see if it works. I'll bet a quarter that it'll work.
>
>This assumes, of course that it's not the DHCP pool, but I believe the
>original poster discounted this already.

Yes, I believe he said that other users are able to come in, sit down,
and get Internet access _after_ he experiences the problem, so it's
not likely to be DHCP pool exhaustion.

>Plugging directly into the router from that computer should answer that
>question easily.

Please explain. Whether wired or wireless, I expect the same DHCP
rules and limitations to apply. Besides, it's usually not easy to gain
physical access to the router at small establishments.

[David Kaye]

"Marcus Allen" <mall...@none.invalid> wrote

> Please explain. Whether wired or wireless, I expect the same DHCP
> rules and limitations to apply. Besides, it's usually not easy to gain
> physical access to the router at small establishments.

Okay. We know that others can log on wirelessly and they get proper DHCP.
So, we know that the router is assigning DHCP properly, but the user's
computer is not getting it. So, it's likely that the problem is in the
user's computer, not in the router.

Fine, but this doesn't quite solve it. Is the problem in the computer's
software or hardware? Well, if he can plug an ethernet cable into the
router (and I believe someone here said that this could be done for test
purposes) and the DHCP works, this means that the problem is more likely to
be the computer's wi-fi hardware (which is usually a small module located
near the HD or battery) rather than come munged software.

And as I also mentioned, if the user can plug in a USB wi-fi and it works,
we definitely know it's the computer's wi-fi module.

If a direct connection doesn't get proper DHCP then there is something amiss
in software, maybe a munged file, an update gone awry, whatever.

[Marcus Allen]

Thanks, David. I see what you're getting at now.

[Kevin McMurtrie]

In article <jripl9$rc6$1...@dont-email.me>,

sudo tcpdump -vvv -i en0

(replace 'en0' with 'en1' or whatever your WiFi happens to be. It
varies.)

I don't know what it would mean for the renew process to end too
quickly. Either the router rejected the request or it's so broken that
it's not reliably responding. It does sound like it ran out of
addresses. Most consumer routers can not handle clients coming and
going on their factory configuration.

[JC Dill]

On 16/06/12 1:17 PM, Peter Lawrence wrote:

> But a relevant question is: do all the MacBooks users that are trying to
> use the same WiFi that you are trying to connect to are having the same
> problem as you?

No. (I've asked.)

> If not, why not?

Unknown.

> When you're having problems connecting to the WiFi, launch the Mac's
> "Activity Monitor" app to see what other processes are running. Some
> third-party software, like the EasyShare app from Kodak likes to add
> background processes at startup. These type of processes may be
> interfering with your Mac's ability to connect to a WiFi network.

I don't have anything like Kodak's EasyShare crap installed on this
computer.

Did you isolate the problem for your family's computers to any specific
software?

jc

[Peter Lawrence]

Yes, disabling the EasyShare background process (had to edit a Mac unix
startup file to do that) and removing a Logitech webcam app that also was
launched at at startup caused the instances to be cut down quite dramatically.

One thing that also often worked on my old Mac laptop (my iBook G4) that
exhibited this type of problem at times on public WiFi networks was to have
the iBook "forget" the WiFi network it was having difficulty establishing a
connection with and then re-select the problematic network. A good number
of times, that did the trick.

That usually solved a problem with a network that the iBook had previously
connected to in the past, so I think it might have cached some configuration
settings of the WiFi network that needed to be cleared from its memory by
"forgetting" the public WiFi network in question.


- Peter

[JC Dill]

On 19/06/12 12:05 AM, Peter Lawrence wrote:
> On 6/18/12 11:01 PM, JC Dill wrote:
>> On 16/06/12 1:17 PM, Peter Lawrence wrote:
>>
>>> But a relevant question is: do all the MacBooks users that are trying to
>>> use the same WiFi that you are trying to connect to are having the same
>>> problem as you?
>>
>> No. (I've asked.)
>>
>>> If not, why not?
>>
>> Unknown.
>>
>>
>>> When you're having problems connecting to the WiFi, launch the Mac's
>>> "Activity Monitor" app to see what other processes are running. Some
>>> third-party software, like the EasyShare app from Kodak likes to add
>>> background processes at startup. These type of processes may be
>>> interfering with your Mac's ability to connect to a WiFi network.
>>
>> I don't have anything like Kodak's EasyShare crap installed on this
>> computer.
>>
>> Did you isolate the problem for your family's computers to any specific
>> software?
>
> Yes, disabling the EasyShare background process (had to edit a Mac unix
> startup file to do that) and removing a Logitech webcam app that also
> was launched at at startup caused the instances to be cut down quite
> dramatically.

That could also be coincidences, since it did NOT solve the problem.

In my case, the "incidences" are random. I can go weeks or months
without the problem popping up, only to have it pop up 3 times in a
week. A change in incidence frequency appears to be entirely
coincidental, rather than due to any software I've added or removed.

> One thing that also often worked on my old Mac laptop (my iBook G4) that
> exhibited this type of problem at times on public WiFi networks was to
> have the iBook "forget" the WiFi network it was having difficulty
> establishing a connection with and then re-select the problematic
> network. A good number of times, that did the trick.

That's a work-around, not a solution. I'm trying to get to the root of
the matter, find out what - exactly - is going wrong, and then how -
exactly - to fix it so that the problem stops entirely, forever.

> That usually solved a problem with a network that the iBook had
> previously connected to in the past, so I think it might have cached
> some configuration settings of the WiFi network that needed to be
> cleared from its memory by "forgetting" the public WiFi network in
> question.

The underlying problem is that there's something broken in how the Mac
does DHCP. This is manifested in a DHCP renew/refresh "finishing" (with
a 169 address) far too quickly, versus the time it normally takes for
this process to finish.

jc

[Peter Lawrence]

On 6/19/12 6:43 AM, JC Dill wrote:
>
> The underlying problem is that there's something broken in how the Mac does
> DHCP. This is manifested in a DHCP renew/refresh "finishing" (with a 169
> address) far too quickly, versus the time it normally takes for this process
> to finish.

There could be, or it could be some third-party software causing the
problem, causing your Mac to time-out too quickly while trying to establish
a WiFi connection.

As a way to gather more information, I would suggest that you launch your
Mac's Activity Monitor app whenever you experience this problem, to see what
processes are running at the time. Activity Monitor shows the processes in
real time, so you can watch what processes are running (or are launched)
when you try again to establish a WiFi connection that has previously failed.

This could give you leads on what to look at. As a point of reference, you
should watch through Activity Monitor what processes are running or get
launched when you successfully connect to a WiFi network too so you can note
the differences during the times you are unsuccessful.


- Peter

[NoOp]

On 06/16/2012 11:02 AM, JC Dill wrote:
> On 15/06/12 9:08 PM, Kevin McMurtrie wrote:
>
>>
>> Network preferences -> Advanced -> Renew DHCP Lease
>
> Does not work. The renew process "ends" far too fast, it's clear that
> the Mac is not properly talking to the router and waiting for a DHCP reply.
>
> I was just having coffee with Jeff at Coffee 9 in Ben Lomond, and Jeff
> got to see this problem in person. He couldn't fix it. He knows the
> owners of this cafe and could reboot the router, which he did, then the
> laptop was able to connect.

Cool. So both you *and* Jeff captured all of the standard information to
troubleshoot the problem... right?

My approach would be to get standard information at the time of the
failure. Simple first:

$ arp
$ netstat -rn
$ ifconfig
$ cat /etc/resolv.conf
$ iwconfig
$ iwlist scan
$ ping
etc., etc.

And of course he also checked the router logs to see what occured there
as well... right?

Perhaps if you two posted some of the details, other than "there's
something broken in how the Mac does DHCP.", others might be able to
offer better solutions.

> But this is not an option at most places,
> and it's not a fair solution when others who are using the wifi have no
> problem getting a routable IP address.

IMO it's a poor "solution" regardless. I've only found that necessary
when the router firmware was the primary issue. What did the router logs
show prior to rebooting the router? What did your logs show before and
after the router was rebooted?

[JC Dill]

On 19/06/12 6:27 PM, NoOp wrote:
> On 06/16/2012 11:02 AM, JC Dill wrote:
>> On 15/06/12 9:08 PM, Kevin McMurtrie wrote:
>>
>>>
>>> Network preferences -> Advanced -> Renew DHCP Lease
>>
>> Does not work. The renew process "ends" far too fast, it's clear that
>> the Mac is not properly talking to the router and waiting for a DHCP reply.
>>
>> I was just having coffee with Jeff at Coffee 9 in Ben Lomond, and Jeff
>> got to see this problem in person. He couldn't fix it. He knows the
>> owners of this cafe and could reboot the router, which he did, then the
>> laptop was able to connect.
>
> Cool. So both you *and* Jeff captured all of the standard information to
> troubleshoot the problem... right?

Wrong. We were both too time strapped with other things that we were
running late to move on to, so it was a matter of trying a few things,
then rebooting the router so I could get online and Jeff could go on to
his next appointment.

> My approach would be to get standard information at the time of the
> failure. Simple first:
>
> $ arp
> $ netstat -rn
> $ ifconfig
> $ cat /etc/resolv.conf
> $ iwconfig
> $ iwlist scan
> $ ping

Ping?

What, pray tell, do you suggest trying to ping when the computer has a
self-assigned 169. address? And what do you learn by that ping?

> etc., etc.
>
> And of course he also checked the router logs to see what occured there
> as well... right?

I don't think Jeff has access to the router logs. He can *reboot* the
router (unplug, replug), but I don't believe he has any login access.

> Perhaps if you two posted some of the details, other than "there's
> something broken in how the Mac does DHCP.", others might be able to
> offer better solutions.

Perhaps if we weren't both short of time, we might have done so. But
given our time constraints, I posted what happened. Maybe next time
I'll have more time. For now, I just wanted to let people know that
Jeff saw it happen and was as stymied as I was about how to get it
resolved as none of the usual "first steps" one takes to try to debut
this type of problem (e.g. trying to refresh/renew the IP) were
accomplishing anything, and since we were short of time he rebooted the
router....

jc

[Jeff Liebermann]

On Tue, 19 Jun 2012 18:27:11 -0700, NoOp <gl...@sbcglobal.net.invalid>
wrote:

>Cool. So both you *and* Jeff captured all of the standard information to
>troubleshoot the problem... right?

No. I don't have access to the router beyond cycling the power.
I had a short discussion with the guy that maintains the router. Let's
just say he treats me as competition and doesn't want me anywhere near
his customers.

>My approach would be to get standard information at the time of the
>failure. Simple first:
>
>$ arp
>$ netstat -rn
>$ ifconfig
>$ cat /etc/resolv.conf
>$ iwconfig
>$ iwlist scan
>$ ping
>etc., etc.

I did some of that. arp -a had some residual addresses from a
previous connection using a tethered cell phone for internet
connectivity. ifconfig showed 169.254.xxx.xxx but the network tools
shows blanks, which is all wrong. I also ran:
sudo ifconfig en1 down
sudo ifconfig en1 up
which shut down the wireless interface, but didn't bring it back until
I used the GUI tools to turn it back on. It's as if the GUI and the
command line utilities have become unlinked. JC also had about a
dozen windows open, all with current work in progress, that I didn't
want to trash by rebooting. We were also working on switching cell
phones, so this was not a great time to do proper testing.

Another clue was that the laptop was able to obtain a DHCP address
after I power cycled the router. However, about 20 minutes later, the
laptop again reverted to 169.254.xxx.xxx requiring yet another power
cycle of the router. There were only 3 people in the coffee shop
using laptops, and I asked two if they wouldn't mind if I reboot.
After the 2nd reboot, the laptop was able to again connect properly.

I also observed that DHCP refresh instantly returned a 169.254.xxx.xxx
address, as if it wasn't even trying to get a new DHCP assigned IP
address from the router. I tried convincing the OS to forget about
the connection, but deleting the SSID from the list of connection, and
by running arp -d IP_address, but it continued to give instant
169.254.xxx.xxx addresses until the router was rebooted. Frankly, I
was skeptical that there was a problem with the MacBook Pro, until I
saw it for myself.

Oh, the router is a WRT54G. I couldn't see the hard revision on the
SN tag. I think it's running the stock firmware.

>And of course he also checked the router logs to see what occured there
>as well... right?

The stock WRT54G does will do SYSLOG but doesn't show connection
progress details. Few cheap routers have the horsepower to do that. I
don't have access to the router config anyway. I could probably hack
my way in, but I'm not interested in pissing off the owners. It
should be possible to simulate the problem in my palatial office, but
it will take hours to do the necessary data collection. It's the lack
of time and the complexity of the problem, that has prevent an instant
solution.

>Perhaps if you two posted some of the details, other than "there's
>something broken in how the Mac does DHCP.", others might be able to
>offer better solutions.

I we had the time to obtain some of the details, we wouldn't need to
post them to the newsgroup. My guess(tm) is that there's some program
that's trampling on the DHCP network function. I see this
occasionally on PC's and Linux. It's not difficult to create such a
problem, but very difficult to troubleshoot.


--
Jeff Liebermann je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

[NoOp]

On 06/20/2012 12:22 AM, JC Dill wrote:
> On 19/06/12 6:27 PM, NoOp wrote:

...

>
>> My approach would be to get standard information at the time of the
>> failure. Simple first:
>>
>> $ arp
>> $ netstat -rn
>> $ ifconfig
>> $ cat /etc/resolv.conf
>> $ iwconfig
>> $ iwlist scan
>> $ ping
>
>
> Ping?
>
> What, pray tell, do you suggest trying to ping when the computer has a
> self-assigned 169. address? And what do you learn by that ping?

Well... perhaps I should have detailed the pings for you? Pinging
localhost (IPv4 and IPv6) generally will give you an indication of
loopback interface issues.

$ ping localhost
$ ping 127.0.0.1
$ ping6 ::1

I typically start there, fix any related issues, and work my way out.

$ ip addr
$ ip neigh

can also be helpful.

>>
>> And of course he also checked the router logs to see what occured there
>> as well... right?
>
> I don't think Jeff has access to the router logs. He can *reboot* the
> router (unplug, replug), but I don't believe he has any login access.

That is now clear in his added reply - thanks.

>
>> Perhaps if you two posted some of the details, other than "there's
>> something broken in how the Mac does DHCP.", others might be able to
>> offer better solutions.
>
> Perhaps if we weren't both short of time, we might have done so. But
> given our time constraints, I posted what happened. Maybe next time
> I'll have more time.

Well at least now you have a place that you may be able to replicate the
problem. Go back & have an other coffee and see if it does it again.
Even if it doesn't, capture the basic info and save it to a text file so
that you can review later and/or give to someone who can assist.

> For now, I just wanted to let people know that
> Jeff saw it happen and was as stymied as I was about how to get it
> resolved as none of the usual "first steps" one takes to try to debut
> this type of problem (e.g. trying to refresh/renew the IP) were

You didn't say exactly what "first steps" you took, nor did you provide
any details. So basically you're back to square one and

"There's a long standing bug in OS X
where the DHCP handshake doesn't work right, and Apple's "solution" is
to give the computer a self-assigned IP starting with 169. which is a
non-routable IP address. This is a completely USELESS "solution".

People have been complaining about this in Apple forums for YEARS:" blah.

> accomplishing anything, and since we were short of time he rebooted the
> router....
>
> jc

Were I you, I'd just hire Jeff (or similar) to troubleshoot your system
& be done with it. No amount of posting "The underlying problem is that

there's something broken in how the Mac does DHCP. This is manifested
in a DHCP renew/refresh "finishing" (with a 169 address) far too
quickly, versus the time it normally takes for this process to finish."

here without details will resolve your issue. Everything else is
guessing in any response. Good luck.

[JC Dill]

On 20/06/12 6:19 PM, NoOp wrote:

> Were I you, I'd just hire Jeff (or similar) to troubleshoot your system
> & be done with it.

It is *extremely* difficult to troubleshoot a sporadic problem. When
the problem doesn't occur, you don't know if you fixed it, or if it's
just in the "not failing now" phase of the sporadic failures.

I've had it happen that I can't connect to a coffee shop one time
(getting a 169. self-assigned address), but connected without problems
previously, and can connect again without problems on subsequent visits.

jc

[JC Dill]

On 20/06/12 9:30 AM, Jeff Liebermann wrote:
> JC also had about a
> dozen windows open, all with current work in progress, that I didn't
> want to trash by rebooting.

I also want to note that I *have* rebooted in some instances when this
problem occurred, with only sporadic success at getting a valid IP
address. When the problem occurred at the Day's Inn in Chandler AZ, it
happened to my dad's laptop (also a macbook pro), and we rebooted his
laptop several times with no success.

jc

[dennis....@gmail.com]

This is obviously an old thread, but I was searching high and low for a solution to this, as well. Nothing seemed to work. I could only connect to my home wifi using a manually specified IP. At work, DHCP worked just fine.

Someone in this thread mentioned 3rd party software, and I got to thinking of what I installed around the time I started having this happen.

A lightbulb went off: Parallels.

I literally just now cleared the manually assigned IP, turned off my wifi, killed Parallels, and turned the wifi on. Bingo. A fresh, clean, wonderful, beautiful, and -most importantly- working dynamic IP address.

That's the first dynamic IP address at home I think I've had since installing Parallels 4 months or so ago.

I doubt anyone will ever look at this thread again, but I'm so happy, I don't mind talking to no one.