Self Assigned IP / DHCP problem : sharing my fix.

Okay. I WAS frustrated for a long two weeks before I figure this out. It seems that this problem has affected a LOT of people out there, and since I now am (supposedly) free of this thing, I want to share my hypothesis of the problem's roots (A) and my fix (B).

Note that:
- i'm free of this problem since the last one week, so .. well, hopefully this is right.
- the problem happens almost anywhere, with any router types, and in any connection type, be it ethernet or wireless a/b/g/n.
- the problem is automagically fixed by running into safe mode.
- the problem keeps happening again and again, although you have powercycled everything of the electronic peripherals in your house, even by disconnecting your phone/ADSL line and main power fuse.
- disabling the Mac OS X Application Firewall sometimes cures it, but most of the time it happens again.
- AFAIK (correct me if i'm wrong), the ipfw, mother of all OS firewall, exists within Mac OS X, and the Mac OS X Application Firewall (i call this OSXAF) has nothing to do with ipfw.

A. My hypothesis and the reasons.
* for an unknown reason, there is a rule created for ipfw that tells it to block the ports 67 and 68, both are the common DHCP ports.
* because of that, your Mac cannot contact with any DHCP servers, anywhere. This forces your mac to assign an IP address by itself.
* disabling OSXAF incidentally removes that rule, but after (one or a few times) reconnect or reboot, the rule appears again.
* powercycling your routers or anything related does not concern ipfw, thus has no effect whatsoever to the problem.

B. My fix.
1. Get the WaterRoof free ipfw frontend (forgot the site, just google)
2. Open it.
3. Go to Static Rules part.
4. Find everything which reads "deny blah blah blah port blah,blah,67,68,blah blah"
5. Edit those rules so that there is no 67 and 68 inside.
6. Open tools -> rules configuration -> save to startup configuration -> yes.
7. Open tools -> startup script -> install startup script -> yes.
That's all.

For me, this seems to be a permanent fix. Please note that the startup script mentioned before exists in all *nix-based machines, so don't worry about startup time, there'll be no slowdowns (again, please correct me if i'm wrong, i had only little experience with *nixes). Besides, i suspect that if you don't save and reinstall that script, the previous script is the one which has 67 and 68 inside.

Hopefully this helps. Any corrections, comments, suggestions, and/or knowledge are welcome.

Cheers,
-bam, the noob.

Macbook2,1, Mac OS X (10.5.4), SMC wireless b/g router/ADSL modem

Posted on Sep 19, 2008 5:51 AM

Reply
14 replies

Sep 19, 2008 8:10 PM in response to apt2k2

Certainly an ipfw rule blocking ports 67 and 68 would disable DHCP, but since this isn't an issue for the vast majority of Mac OS X users, no such rule is created by default.

One possible way something like this can occur is if custom ipfw rules were created for Mac OS X Tiger and the system was updated to Leopard, as (as you noted) both ipfw and the Mac OS X Leopard application firewall run concurrently with ipfw's packet-based firewall taking precedence.

Sep 21, 2008 6:41 PM in response to Dogcow-Moof

Thanks!

In fact, my system was bought used, and it was Tiger back then.

What's bothering me is, I've been running Leopard for at least 4 months now; the wireless router in my home is there since early 2007 and I was able to connect back then, with Tiger 10.4.8, 10.4.9, 10.4.11, Leopard 10.5.0, 10.5.3, and 10.5.4. This particular problem only appears suddenly 3 weeks ago, and that is quite a long time since I last time updated (my last update was 10.5.4).

Actually the interesting thing is, when I googled for this problem, there are also Tiger users experiencing this (it confirms that ipfw is the culprit) and the common temporary cure is flushing ipfw rules, disabling OSXAF, and start in safe mode. All of them also says that the problem appears suddenly.

What bothers me is Who or What created the "block 67 and 68" rule ? Hmm ..

Regards,
-bam

Sep 22, 2008 6:18 AM in response to apt2k2

I'm with William on this one... the FW, while obviously producing this problem for you, is not the real culprit or almost all Mac users would have big issues. I've never had DHCP blocked on a Mac.

Given you've had it working flawlessly for that amount of time, points to an issue in something that occurred when you lost the ability to obtain DHCP addresses.

Sep 23, 2008 3:26 PM in response to jdelima

OK, so a little background -

I have an MBP with 10.5.5 (which I downloaded yesterday, so that's not the issue). This year at school they upgraded the wireless system and network control to Foundry routers and Bradford Securities Network Control. Problem is, my computer is intermittently and randomly having a hard time sticking with one IP and staying away from a self-assigned 169 IP. The System Prefs are fine, and even when I change to manual settings for the IP, it doesn't stick. I checked the terminal (tcpdump) and it seemed to be having a tough time accepting one of the two IPs the servers offered (there are two servers for redundancy). It asked for an IP, gets two offers, and then asks again. I was stumped, and so were the IT guys on campus. And it's not just me, many other 10.5 users are having the issue. And it's not the network, because nobody else is having the issue but 10.5 users. Certificate problems are similarly eliminated from possibility.

The IT guy showed my this thread, and I was excited, so I first tried to just shut off the Firewall all together, and that worked, briefly, but now it doesn't matter if the Firewall is on or off, the problem persists. I tried your WaterRoof method, and the similar program NoobProof, but there were no rules relating to ports 67 or 68 at all, let alone denying them. (As a side note, when my FW is off, there's only the rule allowing all IPs in and out, and when it's on (but only allowing specific programs) it gives a second rule that denies "icmp from any to me in imcptypes 8." No idea what that means.) I've been watching tcpdump and the FW logs closely (as well as the console itself), but nothing has changed. The only interesting thing is that when the IP changes from the (good) 137 IP I'm supposed to have to the (bad) 169 IP, often times (in fact, most times) there is no firewall activity. The console says that the en1 link (wireless) is now down, and the tcpdump picks up the computer asking for an IP again, but the firewall logs pick up nothing, neither through the console or through WaterRoof. Which is weird, because I thought it was a FW problem (as did the IT guys), but the logs show that only occasionally when the servers offer me an IP does the FW block the request, but not all the time.

As another point to note, this is not only an issue with the wireless. The wired connection (Ethernet right into the wall, and attempted from many different plug-in sites) also has this issue.

My only conclusion is that the FW is buggy, or that the logs are missing denials, neither of which makes much sense, IMHO.

Any thoughts?

EDIT: Shutting off the FW often solves the problem, but not always. Sometimes I can get a correct IP even with the FW in full swing without anything popping up in the logs. And sometimes I can't.

Message was edited by: kangasaurus

Sep 25, 2008 6:07 AM in response to kangasaurus

You've stated that your conclusion is that the FW is buggy, and then added a note at the end stating that with the FW on or off you still have intermittent issues, AND with the FW on or off it can also work perfectly... You also state that a wired connection shows the same issues.

At the start of your post you inform us that your school has just upgraded their comms gear...

Given that you have the same issues wired or wireless with the FW on or off, it's clear that the Mac is not the issue. Debugging on the Mac therefore won't yield anything useful (as you've already seen). Talk to your IT guys again - it's their problem.

Sep 26, 2008 8:49 AM in response to jdelima

I have to jump in here. I'm having the same DHCP problem mentioned above and I do believe it is a problem with the OSX Firewall. It is not a network problem. I have determined this by testing on 3 different networks in 3 different locations. 2 wireless, 1 wired. In all cases I got a self-assigned 169 IP address. In all cases I was able to fix the problem (temporarily) by setting the firewall to "allow all incoming connections". Once I do that I can obtain a valid IP. I can then set the firewall back to "set access for specific services..." and it'll continue to work. However, every time I try to get on a new network, I have the problem again.

There is another thread about this issue here:

http://discussions.apple.com/message.jspa?messageID=6240986

That thread suggests trashing 'com.apple.alf.plist' and rebooting. This has worked for me so far (today) but I have only been on one network so I haven't been able to fully test yet.

Now, I've had my Powerbook for over 4 years and never had this problem. It only started when I accidentally let the battery drain all the way down to a point where the date got reset. I don't know if this has anything to do with the issue or not but I suspect that it does. Is this when the problem started for anyone else?

I'm hoping more people can jump in here so we can get to the exact cause of the problem and find a permanent solution.

Like I said previously, I've narrowed it down to OS X. It is not a network issues. I also believe it is a Firewall issue. Any input will be greatly appreciated.

Sep 27, 2008 1:01 AM in response to Yamar

The bottom line is that configd, the daemon that deals with network configration, should always be in the firewall's "exceptions" list.

To check if it is on your system, you can do the following in terminal:

plutil -convert xml1 -o /tmp/1 /Library/Preferences/com.apple.alf.plist

If you then look at the file /tmp/1 with your favorite editor, you should see a section that looks like this:

<key>exceptions</key>
<array>
<dict>
<key>path</key>
<string>/usr/sbin/configd</string>
<key>state</key>
<integer>3</integer>
</dict>


If you don't, you may want to try deleting the plist in /System/Library:

sudo rm /Library/Preferences/com.apple.alf.plist

and see if it then gets recreated properly.

Don't forget to:

rm /tmp/1

when you're done.

Sep 28, 2008 7:15 AM in response to apt2k2

I've had exactly the same self assigning IP problem over the past few days. The IT guys at the company could not resolve the issue, so I ended up traveling some 4 hours to the nearest Apple service centre to watch them turn on my imac and for them to tell me that there was no problem.
Get back to the office, same problem.
After finding this discussion on Apple I decided to get to grip with my firewall, not being so tech minded I was not totally sure how they work.
I run an extra firewall by Netbarrier X5. I opened the application and tried to trace my required IP address, for some unknown reason I find it on the stop list !!!!, I removed it and I get my internet and mail connection back.
Maybe my experience can shed a little more light on this problem.
Thank you

Sep 28, 2008 6:01 PM in response to Dogcow-Moof

Just to say I have the exact same issue as everyone else on this thread, but only on my MBA (10.5.5) My Mini (10.5.5 - Wireless to Airport Express) and MacPro (Wired LAN) do NOT, so far, show the problem. The only difference I can think of is that the Air moves around networks, the other two don't.

The symptoms are the same as everyone else, a self assigned IP clearable by switching the firewall on and off.

My alf.plist does contain the exception detailed in the comment above.

There was a 10.5.5 Combo update and a security update applied between not having the issue and noticing the issue. I suspect the security update changed something as this is not something that has happened prior to that installation.

Oct 2, 2008 9:37 AM in response to David Greenhalgh

In my case, I noticed that disabling OSXAF instantly clears all ipfw rules, BUT rebooting causes the rules to appear again. enabling and re-disabling it clears them again, only to reappear at next boot time (as I mentioned in the first post)

anyone can argue about this sudden strange ipfw behavior, but I'd really suggest that everyone who has this problem check their ipfw, at least using sudo ipfw list..

(In fact, I didn't even KNOW that ipfw EXISTED in OSX before I had this problem ! I understand ipfw a bit because of my late PC was running Ubuntu.)

Oct 4, 2008 2:19 AM in response to apt2k2

I have the same problem, yet different.

my computer will connect, yet after it falls asleep, and then i wake it back up, it wont connect, and it says "self assigned IP"
after a reset of my router, its good to go again,

although, after a bit of walking, it works, its still inconvenient.
does anyone have any suggestions on how i can fix this?

Oct 5, 2008 4:50 AM in response to kjbasdhj

Your problem, as many people stated, and based on my googling, most probably is caused by some misinterpretation-or-whatever about the 802.11n standards. The current temporary cure that usually works is, disable the 802.11n capability of your router, and fallback to 11g.

I'm not a networking expert, though.

Hope this helps.
-bam

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Self Assigned IP / DHCP problem : sharing my fix.

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.