HELP, More DHCP Issues

[s814jdh]

I just got a brand new router from Amazon to replace one that I was having big DHCP issues with. Had to replace it because as soon as the 2.4 radio was enabled the entire router (both wired and wireless connections) became unstable with the first one.

Happily the new router doesn't go completely unstable, the wired connections are fine, but I am still having big problems getting wireless connections to work. Here is what is in the syslog:

Dec 12 20:55:35 dnsmasq-dhcp[682]: DHCPOFFER(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
Dec 12 20:55:35 dnsmasq-dhcp[682]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:c6
Dec 12 20:55:35 dnsmasq-dhcp[682]: DHCPOFFER(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
Dec 12 20:55:35 dnsmasq-dhcp[682]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:c6
Dec 12 20:55:35 dnsmasq-dhcp[682]: DHCPOFFER(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.132 xx:xx:xx:xx:xx:bf
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPREQUEST(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPACK(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6 iPhone
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.132 xx:xx:xx:xx:xx:bf
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPREQUEST(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPACK(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6 iPhone
Dec 12 20:55:37 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
Dec 12 20:55:38 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6

Looks to me like the iPhone is asking for an IP address, the server suggests one, and the phone is declining it? What is going on here? I can't get wireless connections to work. Using Merlin firmware 3.0.0.4.246.19b.

Should mention I have power cycled the router multiple times. I have power cycled the iPhone multiple times. Wired connection from a PC is having no issues at all. Can't get wireless connection to work from iPhone or PC.

 

[KevTech]

I would upgrade to the latest firmware and go from there.

I would also blank out those MACS or at least part of them.

 

[octopus]

The problem isn't your Iphone it's some other IP-adress whos is declining it

Other
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.132 28:e0:2c:04:61:bf

Iphone
Dec 12 20:55:36 dnsmasq-dhcp[682]: DHCPACK(br0) 192.168.2.33 20:c9:d0:59:d7:c6 Jeffs-iPhone-2

Do you use macfilter or static IP ?

octopus

 

[RMerlin]

Also make sure no other device has the same name (Jeffs-iPhone-2).

 

[s814jdh]

Darn it, usually more careful with the MAC. Was so frustrated with things not working that I forgot this time. Could you guys blank them out on the replies you gave too?

I started out with the very latest Merlin firmware first, same issue. Remembered that the reason there was a .19b release was to fix wireless issues with N66U, so thought I would go with that one.

There were multiple iOS devices asking for IPs and all of them were declining the suggestion from the DHCP server. iPads, iPhones, iPod touch. So that is what the other MAC was in the log I posted. In fact, there weren't any wireless connections in the house that were accepting IP addresses the DHCP server was assigning them.

As part of troubleshooting I actually changed to a different IP subnet as well, wondering if somehow there was a conflict with multiple DHCP servers. This change didn't help anything, nothing would accept IP addresses.

I did end up finding a solution, not sure it is the right one or why it worked. This router is the second R66U in the house in less than a week. So that I wouldn't have to re-configure all of the devices that use wireless connections in the house (DirectTV, XBox, BlueRay players, SamsungTVs....) I decided to make the 2.4 SSID and security code be the same as it was configured on the router I sent back (both wired and wireless connections were unstable). In total desperation I decided to change the SSID, and then everything worked great. All of the iOS devices could connect, some PCs, and DirectTV. Have to go back and get the other stuff going, spent 3 hours on this problem and got no where until I changed the SSID.

So, does that make sense to anyone as to why that fixed the problem?

 

[jdabbs]

I would not be concerned about concealing your MAC address. MACs are transmitted in plaintext over wireless networks, so a local attacker would have them anyway.

Your username, however, discloses more information than you might expect.

 

[s814jdh]

I would not be concerned about concealing your MAC address. MACs are transmitted in plaintext over wireless networks, so a local attacker would have them anyway.

Your username, however, discloses more information than you might expect.

Still would rather not have people find my MAC without having to get near me. And you'll notice I took my phone's name out as well. Thanks for the help though.

 

[jdabbs]

MACs are only used for layer 2 communication. They are only useful to someone on the same network as you, and it is almost effortless to obtain it there. Meanwhile, five seconds with a search engine gives me a real name and Google+ account, and potentially a list of people to use in a social engineering campaign. Paranoia only works when you're paranoid about the right things.

 

[s814jdh]

MACs are only used for layer 2 communication. They are only useful to someone on the same network as you, and it is almost effortless to obtain it there. Meanwhile, five seconds with a search engine gives me a real name and Google+ account, and potentially a list of people to use in a social engineering campaign. Paranoia only works when you're paranoid about the right things.

Understand, thanks for the security lesson. Any input on why changing the SSID name fixed the issue? That is what the thread is about.

 

[jdabbs]

Changing the SSID made a difference, but perhaps not in a way you suspect.

Here's what it looks like happened:

Iphone: Yo server, give me an IP.
Router: How about .33?
Iphone: No thanks, that one is already in use. How about another?
Router: How about .33?
~
You change the SSID, which brings the wireless network down. Clients note this as a media disconnection, which causes them to release the IP or request the same IP when another connection is established. Either outcome results in the router having a current lease table. Clients obtain non-conflicting leases and all is right with the world.

Forcing a DHCP release on connected devices would have achieved the same effect, or the problem would have worked itself out when it came time to renew the lease.

 

[s814jdh]

Changing the SSID made a difference, but perhaps not in a way you suspect.

Here's what it looks like happened:

Iphone: Yo server, give me an IP.
Router: How about .33?
Iphone: No thanks, that one is already in use. How about another?
Router: How about .33?
~
You change the SSID, which brings the wireless network down. Clients note this as a media disconnection, which causes them to release the IP or request the same IP when another connection is established. Either outcome results in the router having a current lease table. Clients obtain non-conflicting leases and all is right with the world.

Forcing a DHCP release on connected devices would have achieved the same effect, or the problem would have worked itself out when it came time to renew the lease.

I don't know enough about it to argue against that explanation. But my problem with the explanation is that I powered everything down (iPhone too) and brought it all back up as part of my troubleshooting. Does the N66U keep track of leased IP addresses through a power down? Isn't a full power cycle of the router just as effective as forcing DHCP release on connected devices? I also saw the iPhone go through this process over and over, not just once or twice. It would ask, get the suggested IP back, and then decline it every couple of minutes, endlessly (sucking the battery down like crazy). I even tried to go into the network on the iPhone and manually renew the lease right after a power cycle of the N66U.

Really, what it felt like was that the iPhone was getting things from the same SSID, with the same Router type, everything the same - except the MAC of the router, and rejecting that (having replaced the hardware). Like some kind of strange man-in-the-middle detection iOS is doing or something. Doesn't make sense to me for that either, cause it doesn't seem like that is how things work, but I don't understand why changing the SSID was the magic bullet here.

 

[bluepoint]

It's an interesting SSID bug if it is. Is the SSID one word or multiple? You didn't mention wiping the nvram after each flashing of the firmware, it's also possible you have a corrupt config file if indeed you just moved on from firmware to firmware.

 

[s814jdh]

It's an interesting SSID bug if it is. Is the SSID one word or multiple?

It is one word. I actually only changed it by a single character, but that probably doesn't matter. Went from 7 characters to 8.

 

[jdabbs]

I don't think I've worked with a SOHO router that didn't lose the record of issued dynamic leases* on reboot. Meanwhile, client devices will happily hold on to their leased IP through what they consider a temporary connectivity disruption. This is desired behavior--you don't want to have to wait for the client to get a new IP just because someone fired up a microwave. Rebooting the iphone wouldn't matter, as it was another device configured with the IP in contention. The problem is that how the router handles DHCP could be a lot better. When that DHCPDECLINE message is received, it should temporarily remove that address from the pool and offer another IP. In this case, it didn't, so devices were stuck in an endless exchange.

Having client devices initiate a DHCP request after a DHCP server loses its lease record should be considered best practices. Doing so will reduce the chances of future IP conflicts.


*A static/reserved lease would likely be retained through reboots.

 

[KevTech]

I would not be concerned about concealing your MAC address. MACs are transmitted in plaintext over wireless networks, so a local attacker would have them anyway.

I was not talking about attacking but rather using the MAC.

I could take any of those MACs and clone into the router to get a different IP from my ISP.

People do this all the time when/if they get banned from forums/gaming sites.

 

[jdabbs]

00:23:45:12:ee:85

I just made that up--feel free to use it. You don't even need to understand hex, as it either works or it doesn't. Anyone can do that. There is no magic here.

 

[s814jdh]

I don't think I've worked with a SOHO router that didn't lose the record of issued dynamic leases* on reboot. Meanwhile, client devices will happily hold on to their leased IP through what they consider a temporary connectivity disruption. This is desired behavior--you don't want to have to wait for the client to get a new IP just because someone fired up a microwave. Rebooting the iphone wouldn't matter, as it was another device configured with the IP in contention. The problem is that how the router handles DHCP could be a lot better. When that DHCPDECLINE message is received, it should temporarily remove that address from the pool and offer another IP. In this case, it didn't, so devices were stuck in an endless exchange.

Having client devices initiate a DHCP request after a DHCP server loses its lease record should be considered best practices. Doing so will reduce the chances of future IP conflicts.


*A static/reserved lease would likely be retained through reboots.

Are you saying the issue here was that iPhone was hanging onto an IP address that it was leased several days ago and because the suggested IP provided by the router didn't match the iPhone declined it?

The router did not have any static or reserved IPs setup, in fact, as part of troubleshooting I turned off manual assignment. After power cycling it, all previous DHCP reservations that had been made previously were gone (I checked the list as part of my troubleshooting and saw only the wired PC I was using to fiddle with things). In fact, since my iPhone wasn't connecting I was almost immediately going into the logs and checking for what was going on with DHCP as soon as the router was up enough to get into the admin since that was where I was seeing issues. I would see the iPhone dance with the router, and immediately decline the assigned address, yet the suggested address was put into the reservation table.

I just don't understand why it was that the iPhone was declining the suggested address. It did it over and over. It did at after multiple power cycles. It did it across multiple changes to configuration elements of the 2.4 radio. The only thing that made it stop was to change the SSID, at which point the iPhone decided the suggested IP was finally acceptable.

Oh, and I should mention that I don't think the issue was the IP address of another device was contending, producing a collision. There were as many as 10 devices that would immediately be asking for IP addresses when the router came up, and all 10 of them were given unique suggestions from the DHCP server. I didn't post enough logs for you to see that. I even changed the IP subnet form the 192.168.1 network to the 192.168.2 network just to eliminate that as being a possibility - same issue.

I just don't understand why the iPhone was declining the suggested address right up until the SSID was changed.

 

[bluepoint]

It is one word. I actually only changed it by a single character, but that probably doesn't matter. Went from 7 characters to 8.

Have you reset to factory default(nvram clear) after firmware flashings?

 

[s814jdh]

Have you reset to factory default(nvram clear) after firmware flashings?

Yep, each time I changed the firmware I did that step. This was a brand new router and I wasn't configuring anything else yet, just trying to get the wireless to work, so wasn't going to lose anything by clearing nvram and made sure to do it because there was no cost to it.

Changed the firmware a total of 2 times. Flashed from stock Asus firmware to Merlin 3.0.0.4.260.21 first thing after taking it out of the box. When the wireless connections just wouldn't work, decided to downgrade to Merlin 3.0.0.4.246.19b because I remember reading that the b version was specifically created to address issues with wireless networking. Not only did I clear the nvram with each flash, but I also powered cycled the router with 5 minute wait periods before turning it back on.

Obviously the issue persisted until I changed the SSID. If changing the SSID didn't work I was going to flash back to stock Asus firmware and see if that did anything better. It was very frustrating because after reading threads here for some time now I was confident I was doing that I should be to make sure things went smoothly.

 

[Daybreak]

I just don't understand why it was that the iPhone was declining the suggested address. It did it over and over. It did at after multiple power cycles. It did it across multiple changes to configuration elements of the 2.4 radio. The only thing that made it stop was to change the SSID, at which point the iPhone decided the suggested IP was finally acceptable.

I just don't understand why the iPhone was declining the suggested address right up until the SSID was changed.

Howdy,
Call Apple.

Obviously it was not a problem with the Asus router.