Apple's self assigned IP address sucks

July 26, 2009 10:58 AM

Why does DHCP often suck on open WiFis?

I occasionally have trouble with open wifis at bars and friend's places, thej just never issue an IP address via DHCP, and then my MacBook eventually makes up some worthless IP address.

I can often fix this problem by rebooting the router, but asking a waiter to reboot a router doesn't always get the best results. Are there more effective measures?

Mac OS X apparently doesn't put much thought into the self assigned IP address. Can an IP address be reasonably guessed by sniffing packets? If the router DHCP has crash, will the router itself de dead even with a good IP address guess?

Does anybody have a list of good IP address ranges for different routers?

posted by jeffburdges to computers & internet (20 comments total)

The AP/Router may be configured in such a way that it won't give you an IP address for a specific reason. (it may be "open", but they may be using Mac filtering, they may require you to login through a web-portal before assigning IP's, .... or there may be any number of other reasons.)

The only thing you are doing by rebooting the Router is clearing out the DHCP table. If the Router is located in a busy public place, then its totally conceivable that it has leased out enough IP's to fill up the DHCP table.
posted by jmnugent at 11:04 AM on July 26

Just a data point, not an answer. I've noticed the same thing, and when it happens other people who are trying to connect at the same time can't get an IP Address either.

@jmnugent When routers reach the end of an IP range and "run out" of addresses, are they smart enough go back and start doling out old ones that are no longer in use?
posted by alan at 11:14 AM on July 26

@alan,
DHCP lease time can vary depending on how the Router is configured. (Example, I just looked at my Linksys WRT54G, and it appears the default lease time is 24hours.) I'm not an expert in how DHCP works, but given the above setting (24hrs) .. if you turn on a Router in a busy public spot, and it hands out all 256 addresses in the first hour or two... then I would expect it would not be able to hand out anymore. (it believes all IP's are "in use" - whether there is active traffic on each IP or not)

This is one of the reasons (other than $$$) that WiFi routers in busy public places often require users to sign into a web-portal before being assigned an IP. This strategy prevents someone from walking by with a smartphone in their pocket grabbing an IP when they never intend to use it.

The person/persons administrating the Router should be responsible enough to monitor their traffic patterns and configure the system to provide "best service" options to clients. Of course, this is often not the case, in coffee shops and such where WiFi is simply turned on and minimally configured. (I had a sandwich shop tell me once: "We make sandwiches, not technology".. ;P
posted by jmnugent at 11:23 AM on July 26

Self assigned (169.254.*.*) IPs are not Apple specific. They are an industry standard for when no DHCP response is available. The idea is you can take a small group of computers and hook them up without DHCP and they all auto assign these random addresses. So you can cobble together a network even without a DHCP server.

If you are seeing these, then it's the fault of the network management, not Apple (or Microsoft, or Linux).
posted by chairface at 11:34 AM on July 26 [1 favorite]

Oh yeah, I forgot to mention: autoassigned addresses are not supposed to be routable. It's by design. Here's the RFC if you feel like some light reading.
posted by chairface at 11:36 AM on July 26

jmnugent has it. A person who knows about networking will do at least two things. (1) Shorten the lease time; an hour sounds about right to me for a coffee shop. Plus, DHCP traffic is pretty small. (2) Widen the subnet mask. There's no reason to use 192.168.1.1/24. If you go to /16 you get ~65,000 addresses. What's less clear, however, is how much configuration your standard consumer grade router offers.
posted by sbutler at 11:48 AM on July 26

I gather one answer is : If I wrote down my last IP address for each cafe, then I could manually steal an IP address. So then my original questions become : Is there a list of likely subnets for different router makes? Is there a packet sniffer that'll identify the subnet, so that I may steal a usable address.
posted by jeffburdges at 12:47 PM on July 26

My DSL modem at home came with a default DHCP pool of less than 10 addresses. It worked fine until I was reconfiguring some network equipment the same day that a bunch of people came over. Then I had to spend the weekeng trying to figure out why no one got an IP above 10.10.0.15.

I don't know who came up with that bright idea, but I found that I have coworkers who have run into the exact same issue, so it must be pretty common.
posted by niles at 12:49 PM on July 26

"... Is there a packet sniffer that'll identify the subnet, so that I may steal a usable address."

Most WiFi routers configured for public hotspots should establish an individual VLAN for each client, to prevent easy sniffing of wireless client traffic. This is usually an additional configurable security setting on the WiFi router or access point. Creating individual VLANs for each client does increase CPU load on the router, so for most inexpensive SOHO grade routers, it pays to keep the DHCP address pool small and the DHCP lease time short, to prevent the router from using cycles and memory on maintaining VLAN support for VLANs no longer in use.

Also, remember that each new client logging into a WiFi router is another NAT connection added to the NAT table in memory. If clients are running more than a few TCP/IP ports each, the NAT table fills up pretty fast, as these small SOHO routers don't usually have a lot of extra memory. And the CPU load for a small router doing NAT goes up sharply, again, in a router which is doing deep packet inspection or even maintaining a stateful firewall, which is usually, again, another configurable security setting on most SOHO routers.

So, for a small coffee shop, with a cheap SOHO router, set up to do the most recommended security settings (VLAN client isolation, NAT, DPI) a setting of 16 client sessions is pretty generous, due to the CPU and memory limits of such small, low cost routers. Most such devices will you to specify up to 254 addresses on a Class C network address block, but that's not usually very practical. All it takes is a few folks coming in and starting Bittorrent clients over the WiFI, to scoop up a lot of the NAT table, and a little router configured like that is quickly hosed.
posted by paulsc at 1:25 PM on July 26

No, you will not be able to manually "steal" an IP address. The lease time indicates that for period n, an IP address is linked to a specific piece of hardware and will not be assigned to other devices. If you went back to one of these hotspots and manually assigned your IP it would not work because the lease would have expired.

Packet sniffing would only help you to see communication between active devices, i.e. ones that were currently using their assigned IPs, and therefore would not be of any use finding out what IPs were available.

To answer the third question, yes most routers use one of a small number of network ranges:
192.168.0.x (Netgears mostly use this)
192.168.1.x (Linksys, 2wire, Zyxel)
192.168.2.x (Belkin)
10.0.0.x
10.0.1.x (Apple Airport Express/Extreme)

However due to the first point I made, this will not help you get an IP if the router does not assign you one. jmnugent's response is almost certainly the reason your connections in public hotspots fail frequently, although one other common reason I see for a Mac failing to get an IP address over wireless is due to interference. This is especially true when the Mac has successfully joined said network before, as it remembers certain data about the network, and starts communicating with the router, then appears to have a full signal, but a self-assigned IP. If it had never connected before, the interference would cause the connection to time out instead.
posted by fearnothing at 1:32 PM on July 26

Grabbing an IP and setting it manually is not your preferred method. Have you tried forcing a DHCP release/renew? Open Network Preferences, go to Advanced mode then switch to the TCP/IP tab. Click on Renew. You should see your new IP address & default route. If not the router really is wedged & you'll have to bother the barista to reboot it.
posted by scalefree at 1:44 PM on July 26

You can not be expected to to a 'login' page if you don't have an IP. HTTP->TCP->IP is the protocol stack there, no IP == no HTTP == no 'login' page for access.

VLAN thing, nope. That's just different SSIDs and WEP/whatever keys and the VLANS are on the other side of the AP going over the wired network. Like how many users could configure their computer to actually use VLAN tagging? It's hard enough to configure and understand on a wired connection. 802.1q would be a fools errand on wireless, duh!, all the info is in the airwaves anyway.

Small DHCP pool, Too long DHCP lease times, Small memory for NAT, Dead DHCP process on router, wireless interference, Slow CPU on router such that it can't respond fast enough to stop your computer from timing out and doing the self-assigned thing.

If you were on windows, I would add that their DHCP sucks balls. And you can usually steal an IP if you know what you're doing. Part of at least windows DHCP process is to ARP for the IP it gets to make sure nobody else is using it. (but that might depend on SOHO AP configuration as to whether it will work once you grab it or not.)

FWIW, I manage >1000 wireless access points, with VLANs on the back side and multiple SSIDs and point-to-point links.
posted by zengargoyle at 2:45 PM on July 26 [2 favorites]

I would guess that these places are giving too long of a lease or using too small of a pool of addresses. If there's only one subnet and the lease is ~one day, and there are more than 254 customers, there are no more IP addresses to give out.

You can manually steal an IP, but it would have to be one that HAS been handed out, but isn't currently being used. If you use one the router doesn't know about, routing will be messed up. It doesn't often work.
posted by gjc at 3:11 PM on July 26

There's no problem with dhcp servers in these little routers. The problem is that non-technical people assume that there is because the generic error message is usually about the DHCP lease. Inability to get a lease usually means an interference issue, wrong wpa key, hung router, trying to connect to the wrong ssid, etc. If you plug the machine into the wired interface you'll get an address quickly.

Rebooting it just resets everything, kicks everyone off, and gives you a chance to beat some of the above issues.
posted by damn dirty ape at 6:03 PM on July 26 [1 favorite]

I have had this problem myself, and I am a network administrator by profession, so am not completely without the faculties to figure it out.

What I finally did was set up a few locations in the mac control panel with different static IP addresses, then it is a matter of a few seconds to cycle through them to figure out which one to use when DHCP acts up. Go to network preferences, and there is a locations box across the top. Create a few new ones, each location can have completely different settings with no interference.

Tip: open a terminal window and type arp -a this will generally still give you a clue what their IP address scheme is if you can't guess.

One place I went they reset the router to default config, and the problem vanished. It probably is due to misconfiguration of some sort. Good luck.
posted by Antidisestablishmentarianist at 6:45 PM on July 26

Oh, make your static outside the DHCP scope, but within the subnet mask. In most routers. x.x.x.250/24 usually does the trick.
posted by Antidisestablishmentarianist at 6:47 PM on July 26

You know what's really funny? I am typing this in a car outside some motel because I had this exact problem at the Family Feedbag Internet Cafe down the road.

Thank you, AskMe.
posted by Sallyfur at 10:00 PM on July 26

I'm not talking about any login screen, WPA, WEP, mac filtering issues; only fully open wifi access points that work some days but not others.

Yes, I've tried Apple's release & renew DHCP lease button virtually every time, but I've only seen that actually work maybe twice out of 8ish years using Mac OS X laptops on open wifis.

Yes, I know for a fact that you can manually steal an IP address if you know the router. I've done this maybe 100 time over said 8ish year period, either by asking another users, or usually just being lucky using 192.168.0.x. I'm aware raouters may have other issues, like the NAT table being full, but I've found that bypassing DHCP solves many problems.

What I want is a tool to simplify this task. An easy solution might be perl scripts that (1) cache the SSID, IP, netmask, router IP, and date of established connections, and (2) retry each appropriate cached configuration. It looks like "airport", "ifconfig en1", and "netstat -rn" will report this information unambiguously, not sure about "arp -a".

I'm still curious however if another lower level tool might help. How about simultaneously sending pings and http requests to all likely router IPs, say {192.168,10.0}.*.{1,100,255}. If one responds, try configuring the network on an IP address in that subnet. Would multicast work for this?

p.s. I'm not too keen on using Apple's network locations. Well I move fairly frequently and already use those for setting DNS operators.
posted by jeffburdges at 6:32 AM on July 27

I'm not talking about any login screen, WPA, WEP, mac filtering issues.
Yes, I've tried Apple's release & renew DHCP lease button virtually every time.
Yes, I know for a fact that you can manually steal an IP address if you know the router.
I'm aware routers may have other issues, like the NAT/DHCP table being full.

What I want is a tool to simplify this task. An easy solution might be perl scripts that (1) cache the SSID, IP, netmask, router IP, and date of established connections, and (2) retry each appropriate cached configuration. It looks like "airport", "ifconfig en1", and "netstat -rn" will report this information unambiguously, not sure about "arp -a".


No offense meant - but if you'd put all of this information in your original opening-comment, the majority of us would have refrained from commenting (and wasting your/our time). It's (now) obvious that you are looking for a much more technical answer than many of us assumed. I again, apologize.
posted by jmnugent at 7:24 AM on July 27

Look for Wireshark, tcpdump, libpcap. I think there are OSX versions. You have ~3 levels to work with. SSID,WEP(whatever) to setup the actual interface, DHCP(stealing addresses), DNS/'login'/MAC filtering(to make the damn thing work).

What I would do... capture DHCP packets to see if your machine actually received DHCP ACK (requires first level of setting up interface for SSID/key), you can packet sniff on an interface without an IP no problem.

Stage 1: get SSID/key and get interface up.
Stage 2: use tcpdump/etc and 'libpcap' to track traffic you see. Get idea of DHCP ranges and MACs and associated IPs. (Perl if you want to automate it.)
Stage 3: wait for one to leave. Learn to use 'ifconfig' to change your MAC address and configure IP/Gateway manually.
Stage 4: Learn to configure routing and DNS, 'route' command'.

Short form... listen for a while and collect MAC-IP mappings. Wait for one to leave, or have better connection and firewall rules to drop NAK packets and just brute-force them off the network. Steal their MAC-IP. Get and learn to use a packet sniffer, you just need SSID and key to make that part work, learn Gateway and DNS. Steal!!!

Portals are pretty much MAC filtering and policy application.
(Sorry, I spend a bit of my time in random closets at 3am totally hacking the system, including looking for an unused connection and totally stealing it)
posted by zengargoyle at 2:09 PM on July 27