HELP, More DHCP Issues

[s814jdh]

Howdy,
Call Apple.

Obviously it was not a problem with the Asus router.

I don't think it was just iOS unfortunately. Win7 PC didn't decline the address, but there was something strange that happened where when the PC was connected both by wired and wireless connections (just for testing, not something that normally would be done) then the same IP was given to both connections and Windows warned of an IP address conflict.

 

[jdabbs]

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?

No. Iphone asks for IP. DHCP server offers IP. Iphone determines IP already exists on the network. Iphone declines address. DHCP server offers the same IP address again because the dev is bad. The process continues.

The router did not have any static or reserved IPs setup, in fact, as part of troubleshooting I turned off manual assignment.

Doesn't matter if a client is configured with the IP.

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).

Doesn't matter if a client is configured with the IP.

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."

Doesn't matter if a client is configured with the IP.

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.

Ideally, the DHCP server would remove the IP from the pool and issue another address. That wasn't happening.

I just don't understand why it was that the iPhone was declining the suggested address.

Because it determined the IP was in use.

It did it over and over.

Because the DHCP server is terrible.

It did at after multiple power cycles. It did it across multiple changes to configuration elements of the 2.4 radio.

Did the IP that was offered and rejected vary between router reboots?

The only thing that made it stop was to change the SSID, at which point the iPhone decided the suggested IP was finally acceptable.

Devices that were previously on the wireless network would have to manually be readded (odds are they wouldn't be configured with the new SSID). The iphone may have obtained a lease before the problematic device was on the network.

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.

Going to a non-overlapping subnet would rule out an IP conflict, at least until the first reboot.

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

There is another explanation besides a duplicate IP on the network--it has to do with how the iphone determines an IP is in use. If the iphone initiates an ARP request for the IP, and another device responds, even if that device doesn't have the IP, the iphone will interpret that as a "taken" and decline the DHCP offer. I would be hesitant to accept this explanation without first understanding why the problem is not happening now.

 

[bluepoint]

How sure are we that the client(iPhone) is declining the DHCP offer? It could also be the DHCP server declining the clients credentials. I'm sure this is not an Apple product problem cause all apple hardwares in my household works with the same router/firmwares except for those Asus stock firmwares with a newer buggy Broadcom drivers after 220. There is a bug somewhere, why did it suddenly works after the SSID was changed?

 

[jdabbs]

How sure are we that the client(iPhone) is declining the DHCP offer? It could also be the DHCP server declining the clients credentials.

Dec 12 20:55:37 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
http://www.ietf.org/rfc/rfc2131.txt
DECLINE is client rejection. NAK is server rejection.

I'm sure this is not an Apple product problem cause all apple hardwares in my household works with the same router/firmwares. There is a bug somewhere, why did it suddenly works after the SSID was changed?

You are focused on the whats when you should be looking at the whys. The problem did not occur after the SSID changed. What if the guy wore Wrangler jeans when he changed the SSID? Should we ask him what color jeans we should buy? You can chalk the thing up to a mystery bug and call it a day, or you can try to understand what is happening in the background and realize there are other factors in play.

 

[bluepoint]

Dec 12 20:55:37 dnsmasq-dhcp[682]: DHCPDECLINE(br0) 192.168.2.33 xx:xx:xx:xx:xx:c6
http://www.ietf.org/rfc/rfc2131.txt
DECLINE is client rejection. NAK is server rejection.



You are focused on the whats when you should be looking at the whys. The problem did not occur after the SSID changed. What if the guy wore Wrangler jeans when he changed the SSID? Should we ask him what color jeans we should buy? You can chalk the thing up to a mystery bug and call it a day, or you can try to understand what is happening in the background and realize there are other factors in play.

Thanks for the rfc, that explains the log. But why would I buy the jeans based on the color. Isn't it better to wear a jeans that is comfortable based on your experience?

I guess what I'm trying to say is, the same setup and hardware works for me why not for the OP. That is the why. I do not agree the iPhone is causing the problem.

 

[jdabbs]

Thanks for the rfc, that explains the log. But why would I buy the jeans based on the color. Isn't it better to wear a jeans that is comfortable based on your experience?

He changed the SSID and the issue resolved itself. He wore jeans and the issue resolved itself. Clearly we need to know the correct jeans are so we can fix the issue in the future. You dismiss jeans as having nothing to do with the problem since you know enough about networking to know that fashion choice has little impact on troubleshooting. I dismiss a SSID change as having nothing to do with the problem since I know enough about networking to know how the clients on the network would react to such an event.

I guess what I'm trying to say is, the same setup and hardware works for me why not for the OP. That is the why. I do not agree the iPhone is causing the problem.

What you are saying is:
I have Apple devices and an Asus router.
I do not have problems.
Since I don't have problems, nobody with Apple devices and an Asus router will have problems.
If they have problems it's not due to Apple.

This is not solid reasoning.

 

[bluepoint]

I dismiss a SSID change as having nothing to do with the problem since I know enough about networking to know how the clients on the network would react to such an event.

Since you know enough about networking, you dismissed the fact that the OP is getting an ip when wired. He's specifically having problem with the wireless clients acquiring ip from the DHCP. My thinking is, if he was able to get an ip from the wired clients from the same DHCP server then something is broken with the wireless. Without changing anything from the clients, when the OP change the SSID, suddenly the problem is fix. Where do you think the problem lies?

What you are saying is:
I have Apple devices and an Asus router.
I do not have problems.
Since I don't have problems, nobody with Apple devices and an Asus router will have problems.
If they have problems it's not due to Apple.

This is not solid reasoning.

I have not seen anyone here having the same dhcp wireless problem with apple products. There are some having problem with the Asus newer wireless driver but it's a different problem. Why don't you tell us what you think, maybe a claimed expert can teach us how to post a solid reasoning.

 

[jdabbs]

Since you know enough about networking, you dismissed the fact that the OP is getting an ip when wired. He's specifically having problem with the wireless clients acquiring ip from the DHCP. My thinking is, if he was able to get an ip from the wired clients from the same DHCP server then something is broken with the wireless. Without changing anything from the clients, when the OP change the SSID, suddenly the problem is fix. Where do you think the problem lies?

If the wired devices were connected to the router via a switch, they wouldn't have had an interface state change, and consequently retained their preexisting leases. Maybe the router's switch loads up faster than the radio, allowing wired devices to have connectivity first. Some devices do not check for duplicate IPs, so they wouldn't reject an IP from the DHCP server. None of this really matters; the logs paint a fairly clear picture of what's going on (see below).

I have not seen anyone here having the same dhcp wireless problem with apple products. There are some having problem with the Asus newer wireless driver but it's a different problem. Why don't you tell us what you think, maybe a claimed expert can teach us how to post a solid reasoning.

I'll do you one better--I'll tell you how to investigate.

The iphone does not have Internet access. Why?
The iphone is not configured with an IP from the DHCP server.
The iphone is rejecting IP addresses offered by the DHCP server.
IP addresses are rejected by the client if it determines the IP is use.

Since rebooting a router purges the DHCP lease table, it is reasonable to assume the router is handing out IPs that were already leased by another device. Changing the SSID kicked all of the wireless devices off the network, giving the iphone a better chance of getting an IP.

Compare this with:

I changed the SSID. Magic happened, and now my iphone can connect.

When dealing with competing hypothesis, you should craft a test where the outcome would support one and reduce support for the others. Since this is no longer an option, the next approach is to attack the hypotheses directly. Changing the SSID is easy to challenge, as you could say the fix was due to something else happening in the background (other devices purging their IPs to connect to the new network, less devices being on the network at the time of connection attempt, etc.) Defending it is much harder, as "magic" lacks explanatory power. You are certainly welcome to try, though.

The other hypothesis (IP conflict) reflects the information initially posted by the OP, but followup information undermines it. If he changed the subnet and the iphone still declined a lease, then you could rule out an IP conflict. If that's the case, then perhaps the method the iphone uses to determine an IP is in use is suspect. As it turns out, there are ways ARP could lead to an incorrect assessment. This leads to the followup question of why the problem happened then and not now, and I can think of a reason why, but there is currently little evidential support other than "well, it's possible."

 

[bluepoint]

That was a good technical lesson from a knowledgeable network guru. As far as I can comprehend your drift is, the cause of the Op's problem is that the DHCP server is offering an ip that the client thinks it's already in use. Fine, it's a possibility. However, the OP has a very simple network and base from the information he posted, he did not have too many clients to be conflicting with ip's. I can not remember the default number of ip's it serves but it's at least more than 100. There are enough ip's available to the OP's clients.

Since rebooting a router purges the DHCP lease table, it is reasonable to assume the router is handing out IPs that were already leased by another device.

Not my experience with this router. Rebooting this router clears all the DHCP leases therefore it can not issue an ip that is already in use. My little knowledge of networking tells me if the DHCP is issuing an ip that is already in use, the server is broken or misconfigured.

Changing the SSID kicked all of the wireless devices off the network, giving the iphone a better chance of getting an IP.

Re-reading the OP's posts it appears all his wireless clients were not getting an ip. All of them now works after the SSID was modified.

 

[jdabbs]

That was a good technical lesson from a knowledgeable network guru. As far as I can comprehend your drift is, the cause of the Op's problem is that the DHCP server is offering an ip that the client thinks it's already in use. Fine, it's a possibility. However, the OP has a very simple network and base from the information he posted, he did not have too many clients to be conflicting with ip's. I can not remember the default number of ip's it serves but it's at least more than 100. There are enough ip's available to the OP's clients.

The number of IPs in the pool doesn't matter if the DHCP server only offers a single "bad" IP to a particular client, repeatedly.

Not my experience with this router. Rebooting this router clears all the DHCP leases therefore it can not issue an ip that is already in use. My little knowledge of networking tells me if the DHCP is issuing an ip that is already in use, the server is broken or misconfigured.

You understand how the DHCP server works, but are ignoring the effects of other clients. Without a lease table, the DHCP server will not be able to tell which IPs have previously been issued. This allows IP conflicts to occur.

Scenario:

1. A router-based DHCP server has a pool of 100 IPs. The first 5 leases (IPs A-E) are issued to clients. The DHCP maintains a record in its lease table.
2. The router is rebooted. The lease table no longer contains any data. When a device requests an IP, the DHCP server will issue the first one it has, IP A.
3. The device that originally had IP A may still be configured with that IP. If the new device notices this, it will reject the lease from the DHCP server and request another address.
4. In this case, the DHCP ignores the fact that IP A was rejected and continues to offer IP A to the new device. The new device will be unable to connect.

Re-reading the OP's posts it appears all his wireless clients were not getting an ip. All of them now works after the SSID was modified.

My policy is to be selective in deciding what information to accept at face value. There was a problem with the wireless clients that he reported. Non-daily use devices like printers or game consoles are often overlooked. My explanation doesn't hinge on the presence or absence of these devices, so it is safe for me to not know one way or another. The existence of a single wireless device that could connect before the SSID was changed would blow a pretty big hole in the "it's wireless" theory, so if I were in your shoes, I wouldn't pin any hopes on the explanation before knowing for sure. Even then, I'd be careful not to place too much weight on shared characteristics. If they were both Apple devices with an aluminum body, would you insist that Apple switch to a plastic casing? Similarities can give hints of where to focus your investigation, but they make for a poor explanation.

 

[bluepoint]

The number of IPs in the pool doesn't matter if the DHCP server only offers a single "bad" IP to a particular client, repeatedly.

True but where will the bad IP come from when there is no wireless client able to connect. Your theory of a bad IP is flawed. At that time his wired pc is the only one that have an IP. Why would the server insist on that one IP while there are plenty available? This scenario can only happen if the IP pool is set at one(1) which I doubt the OP did.

You understand how the DHCP server works, but are ignoring the effects of other clients. Without a lease table, the DHCP server will not be able to tell which IPs have previously been issued. This allows IP conflicts to occur.

Scenario:

1. A router-based DHCP server has a pool of 100 IPs. The first 5 leases (IPs A-E) are issued to clients. The DHCP maintains a record in its lease table.
2. The router is rebooted. The lease table no longer contains any data. When a device requests an IP, the DHCP server will issue the first one it has, IP A.
3. The device that originally had IP A may still be configured with that IP. If the new device notices this, it will reject the lease from the DHCP server and request another address.
4. In this case, the DHCP ignores the fact that IP A was rejected and continues to offer IP A to the new device. The new device will be unable to connect.

Even you are not sure, your statements are not definitive to what actually is happening. Let me fill you up based on my observation and actual experience with this router. Daily wireless/wired clients in my home network(8). When I reboot the router each of them gets the same IP it had before even the wired PS3. In this scenario, even if the wired(PS3) is powered on last, it still gets the same IP. so it seems each of the clients ask for the same IP when they see the router. I also seen when my son comes and his iPhone connects, his iPhone ask for an IP that he had from another network(his home) and the DHCP will respond that it's the wrong network it then offers a vacant network IP which the iPhone accepts.

My policy is to be selective in deciding what information to accept at face value. There was a problem with the wireless clients that he reported. Non-daily use devices like printers or game consoles are often overlooked. My explanation doesn't hinge on the presence or absence of these devices, so it is safe for me to not know one way or another. The existence of a single wireless device that could connect before the SSID was changed would blow a pretty big hole in the "it's wireless" theory, so if I were in your shoes, I wouldn't pin any hopes on the explanation before knowing for sure. Even then, I'd be careful not to place too much weight on shared characteristics. If they were both Apple devices with an aluminum body, would you insist that Apple switch to a plastic casing? Similarities can give hints of where to focus your investigation, but they make for a poor explanation.

But that is exactly the problem, according to him none of his wireless clients can connect and only did it work after changing the SSID. Where else will we start looking at his problem?

 

[jdabbs]

True but where will the bad IP come from when there is no wireless client able to connect. Your theory of a bad IP is flawed. At that time his wired pc is the only one that have an IP. Why would the server insist on that one IP while there are plenty available? This scenario can only happen if the IP pool is set at one(1) which I doubt the OP did.

The IPs are offered in sequence. If the 3rd IP (IP 3) in the pool is in use by an existing client (Client B), then the client (Client A) will continue to ask for, receive, and reject that IP address (IP 3). Another client (Client C) can come along and be handed another IP (IP 4). The problem is the DHCP server sees that it offered IP 3 to Client A, but fails to take into account that the IP was rejected. It continues to hand out IP 3. Eventually Client B will ask the server for IP 3, be rebuffed by the server, obtain a new IP (IP X or whatever is next in the pool), which would free IP 3 for use by Client A, which it finally accepts.

Even you are not sure, your statements are not definitive to what actually is happening. Let me fill you up based on my observation and actual experience with this router. Daily wireless/wired clients in my home network(8). When I reboot the router each of them gets the same IP it had before even the wired PS3. In this scenario, even if the wired(PS3) is powered on last, it still gets the same IP. so it seems each of the clients ask for the same IP when they see the router. I also seen when my son comes and his iPhone connects, his iPhone ask for an IP that he had from another network(his home) and the DHCP will respond that it's the wrong network it then offers a vacant network IP which the iPhone accepts.

Good question. IPs are offered in sequence. What you are seeing is DHCPREQUEST in action.

Device has no existing lease

1. Client: Any DHCP servers out there? I need an IP. (DHCPDISCOVER)
2. DHCP Server X: How about IP 11? (DHCPOFFER)
3. Client: Hey DHCP Server X, IP 11 sounds great, thanks. (DHCPREQUEST)
4. DHCP Server X: Your IP is now IP 11. (DHCPACK)

Device has an existing lease

1. Client: Hey DHCP Server X, can I still have IP 37? (DHCPREQUEST)
2. DHCP Server X: Even if I don't have a record of IP 37, it isn't taken, so ok. (DHCPACK)
3. DHCP Server X updates lease table.

The OP's iphone didn't have a lease, so it was offered the next IP in the pool. Does this make sense?

But that is exactly the problem, according to him none of his wireless clients can connect and only did it work after changing the SSID. Where else will we start looking at his problem?

The iphone is not configured with an IP from the DHCP server.
The iphone is rejecting IP addresses offered by the DHCP server.
IP addresses are rejected by the client if it determines the IP is use.

Rule out IP conflicts if possible (the OP was leaning that way before he left). If ruled out, determine if there was a device that responded to ARP requests which fooled the Apple devices into thinking the IPs were in use. Find out why wired devices were unaffected (I've already listed a few reasons). Find out why that was a problem then, but not now (maybe because it was still configured with the old SSID when the wireless devices requested an IP).

 

[Nerre]

Are the IP addresses really offered in sequence? From what I learned, today DHCP servers offer an IP addressed based on the clients MAC, to make offers more consistent (trying to always offer the same IP to the same machine).

Also, from what I remember, the DHCP server will check if the IP is in use before offering it.

So that the clients rejects an address becuase it think it's in use is as far as I understand it incorrect use of the protocol. The whole point of using a DHCP server is that it is the server that shall keep track of what addresses are in use and not.

How can an address in the pool be in use if the DHCP server has not offered it? That client must be using an address without having requested if from the DHCP server?

 

[mstombs]

Old simple dhcp servers such as udhcpd did allocate IP addresses in sequence, which can cause a problem with re-use, especially if phones/laptops hibernate or go out of range and don't reply even when the server checks the IP is available (which they should all do).

dnsmasq, the dns/dhcp server now used in most routers, uses a MAC hash which means IPs are not allocated in order and clients usually get the same IP even if they are not 'dhcp reserved' in the router config.

If you use static IPs on your lan its always a good idea to also define them in the router so you can connect by name as well as ensure no attempt to give that IP to another device.

 

[s814jdh]

More Details

Had some time off but thought I would provide some details around the issue so that there isn't any confusion.

First I think I should mention that I don't believe there is a huge problem with using Apple devices with the Asus RT-N66U. I have one in my home that has never really had a problem to date (10 months as of this post), and it is on an older stock firmware (not touching something that isn't broken). The issue I have described in this thread is something that happened at my in-laws house. I think the single biggest contributing factor was an actual lemon of an N66u that Amazon happily accepted a return on.

I don't want to have someone read through this thread and decide the N66u is not for them because there are issues with Apple devices. I LOVE this router and highly recommend it to anyone.

OK, that out of the way, here is the exact order of events:

1. Bought brand new 66u router from Amazon
2. Unboxed the router
3. Updated the firmware to Asuswrt-Merlin RT-N66U_3.0.0.4_246.20 (latest available at the time) through wired connection
4. Erased NVRAM
5. Customized the SSID and passwords for the wireless network
6. Unplugged the router
7. Connected the WAN port to the Comcast cable modem for Internet access
8. Unplugged the Comcast cable modem, waited for it to come all the way up
9. Powered on the n66u, waited for everything to come up
10. Connected a Win7 laptop through wired connection 4 on n66u, immediately got a good connection and Internet access on the PC
11. Connected 4 iPhones and 2 iPads to the wireless network, all of them connected immediately and had Internet access
12. Connected a Windows XP laptop wirlesslessly without issue
13. Connected DirectTV, Samsung TV, BlueRay player, and XBox 360 to wireless network, all without issue

This configuration worked great for about 4 weeks. My in-laws came back from a trip (so nobody was actively using the router) and found that neither the wireless nor the wired connections were working. No idea what happened to it, but after going through a few hours of troubleshooting (boy those power cycles take a lot of time), it seemed that the issue came down to the 2.4 radio and the DHCP server somehow. The one wired PC was getting messages about IP address conflicts and would only stay up for about 2-3 seconds before Windows would report that the connection was gone, then get connected again in a cycle. If I turned off the 2.4 radio the wired connection became stable, soon as I turned 2.4 back on, everything was toast. This thread was not about the issues at this point. I became convinced the router had somehow gone bad. Returned the router through Amazon, who shipped me a new one immediately with the provision that I return the "bad" one within 30 days (love Amazon).

OK, so here is the sequence now that is more interesting. Remember, there are a number of clients that were configured to run on the network the router provided, most of the wireless.

1. Unbox new router
2. Updated the firmware to Asuswrt-Merlin RT-N66U_3.0.0.4_246.20 (latest available at the time) through wired connection
3. Erase NVRAM
4. Customized the SSID and passwords for the wireless network to be the same as the "bad" router just shipped back to Amazon (being lazy so I wouldn't have to re-configure all of the wireless devices)
5. Power down the router
6. Connected the WAN port to the Comcast cable modem for Internet access
7. Power down the Comcast cable modem, waited for it to come all the way up
8. Powered on the n66u, waited for everything to come up
9. Connected a Win7 laptop through wired connection 4 on n66u, immediately got a good connection and Internet access on the PC
10. Look at iPhone to validate wireless network, it isn't connected.
11. Tell iPhone to forget the wireless network, click to join the network, provide the same password as was configured before, iPhone tries and tries to get a connection and doesn't
12. Look at the system logs on the router, see that the DHCP server is trying desperately to recommend IP addresses to the iPhone (and all the other wireless devices) and it looks they are all declining EVERY suggested IP. The router is suggesting unique IPs to everything (not trying one IP with one device then the same IP with a different device), even multiple different IPs to the iPhone. Check the lease table, there are only a couple of IPs listed in there, but every refresh shows that changing (looks like the suggested IP is put in there until the client declines it). Puzzled why everything is declining the IPs being suggested
13. Power down n66u, cable modem, and iPhone (yes, actually turn it off by holding power button then swiping red bar on the top to power it all the way off)
14. Wait for 5 minutes
15. Power up cable modem, wait for it to be ready (about 3 mins)
16. Power up n66u, wait for it to be ready
17. Power up iPhone, won't get a connection
18. Check the router system logs, same issue with the clients rejecting the IPs being suggested by the DHCP server
19. Remembering that the notes on merlin firmware releases had one specifically about wireless driver issues, flash the firmware to the RT-N66U_3.0.4_246.19b version where that specific issue was addressed by going back to older wireless drivers that were more stable.
20. Erase NVRAM
21. Use wired connection to reconfigure the same SSID and password that has been used (again being lazy and don't want to change the clients in the house)
22. Power down everything
23. Wait for 5 minutes
24. Power up cable modem, wait for it to be ready
25. Power up n66u, wait for it to be ready
26. Check iPhone, still no connection, system logs show the same issue with the different IPs suggested being declined over and over
27. Wonder if there is some issue with the same network and same router make/model with the same IP segment (can't believe that would be true, but desperate here), I change the network to be 192.168.2 instead of 192.168.1.
28. Power down the n66u
29. Wait 5 mins
30. Power up the n66u
31. iPhone still won't connect, system logs show 192.168.2 IPs being suggested and declined by iPhone and other wireless clients
32. Not having any idea what to do so that the clients won't decline the IPs suggested by the DHCP server, decide to try changing the SSID.
33. Without even restarting the router, try to connect to iPhone to new SSID, works!
34. Get the other iPhones and iPads connected, no issue
35. Get all the other wireless devices configured, all work without issue
36. Scratch head at what just happened, why in the world did that fix the problem, wondering if I should be worried that in 3 weeks going to have problems again

So, there you go. Hopefully that helps answer some of the questions that have been posted to the thread. I still don't understand why changing the SSID was the silver bullet. Sure seems like lease tables and anything else that might account for most DHCP issues would be negated by the power cycles of the router, and if not that then changing the IP subnet that was being used should have addressed that. Yet, it was the changing of the SSID that finally convinced those wireless clients that they could accept the IPs being suggested by the DHCP server.

 

[s814jdh]

Rule out IP conflicts if possible (the OP was leaning that way before he left). If ruled out, determine if there was a device that responded to ARP requests which fooled the Apple devices into thinking the IPs were in use. Find out why wired devices were unaffected (I've already listed a few reasons). Find out why that was a problem then, but not now (maybe because it was still configured with the old SSID when the wireless devices requested an IP).

There was only a single device with a wired connection to the n66u, and it didn't seem to have any stability issues along the way. It accepted the IP suggested to it by the DHCP server all along. Didn't try any other wired devices, there really was only one other wired device that needed to be plugged in (VoIP) but wasn't trying to get it to work until the wireless stuff worked. Wanted to make it the simplest configuration possible.

 

[s814jdh]

Root Cause?

OK, as I have been catching up on this thread, reading through the other thoughts on what was going on here, something just came to me that may be the actual root cause of the issue.

After changing the SSID and getting things on the wireless network, I had to get the DirectTV wireless client to connect again. I don't have DirectTV, so this wireless client is new to me, it was actually a little bit difficult to figure out where to go so that I could change the SSID. When I finally found where to do it, at first it wouldn't find any SSIDs in the area, not even those of the neighbors that were so readily seen on the many other wireless clients. After multiple attempts I checked out the box that does the wireless connection and found an Ethernet cable plugged into the back of it, and it led to an unmanaged Netger branded switch. Plugged into that switch was wired connections out to the other entertainment center devices (XBox, BlueRay, TV, etc). So I think it was acting like a bridge there with local clients getting a wired connection that got an Internet connection through the wireless network. I had to disconnect that switch from the DirectTV wireless box in order for it to see the new SSID.

So, is it possible that Netgear switch (that wasn't being power cycled as I tried things) could be the one that was producing the ARP messages that made everyone believe that the IPs being suggested by the DHCP server of the n66u were already in use?

 

[jdabbs]

Are the IP addresses really offered in sequence? From what I learned, today DHCP servers offer an IP addressed based on the clients MAC, to make offers more consistent (trying to always offer the same IP to the same machine).

Some routers record the leases they issue. A lease could expire for IP A originally leased by MAC A. When a lease is requested by MAC B, IP B will be issued even though IP A is technically available. IP A won't be reissued until the IP pool is exhausted, or MAC A requests it again. This will look consistent.

Also, from what I remember, the DHCP server will check if the IP is in use before offering it.

I wish!

So that the clients rejects an address becuase it think it's in use is as far as I understand it incorrect use of the protocol. The whole point of using a DHCP server is that it is the server that shall keep track of what addresses are in use and not.

The server does keep track of what IPs have been issued; this is a lease table. When that lease table is lost, so is the IP lease information. Clients being able to reject an IP is a good thing.

How can an address in the pool be in use if the DHCP server has not offered it? That client must be using an address without having requested if from the DHCP server?

DHCP server offers IP A. DHCP server is rebooted, and loses its lease table. The device with IP A will still have it regardless of whether the DHCP server has that a record of that lease.

 

[jdabbs]

Old simple dhcp servers such as udhcpd did allocate IP addresses in sequence, which can cause a problem with re-use, especially if phones/laptops hibernate or go out of range and don't reply even when the server checks the IP is available (which they should all do).

dnsmasq, the dns/dhcp server now used in most routers, uses a MAC hash which means IPs are not allocated in order and clients usually get the same IP even if they are not 'dhcp reserved' in the router config.

That's actually a clever way of doing things--I hadn't encountered it before, but the documentation for dnsmasq bears it out.

With a limited pool, I imagine that a particular IP might be first-come, first-served. (50 IPs = a maximum of 50 unique hashes, enough for collisions to happen). The predictability of IP assignments would be affected as a result.

If you use static IPs on your lan its always a good idea to also define them in the router so you can connect by name as well as ensure no attempt to give that IP to another device.

It'd be much easier to not assign static IPs in the middle of your DHCP scope.

 

[jdabbs]

So, is it possible that Netgear switch (that wasn't being power cycled as I tried things) could be the one that was producing the ARP messages that made everyone believe that the IPs being suggested by the DHCP server of the n66u were already in use?

The switches I've seen go bad have ports fail or start spewing malformed frames. ARP (convert IP to MAC address) is a layer 3 thing, which consumer switches don't concern themselves with. I'd suspect a device behind the switch, or possibly a switching loop that'd forward frames back into the network.