Confused about DHCP server issues

[PurdueRy]

So I recently reconfigured my network because I bought a WNDR3700 router. My network is configured as follows:

Modem - WNDR3700
WNDR3700 -(wireless bridge)-> WRT54GL -(wired)-> PS3
WNDR3700 -(wired)-> Desktop Computer
WNDR3700 -(wired)-> RT-N16 -(wired/usb)-> Printer/hard drive

I have the WNDR3700 at IP address 192.168.1.1, the RT-N16 at 192.168.1.2 and the WRT54GL at 192.168.1.3

The RT-N16 is configured as a printer/file server. I have the internet port and DHCP disabled. The WRT54GL is configured as a wireless bridge and so it doesn't have its DHCP server enabled. I've found a router is better than the PS3's internal wireless adapter by a significant margin.

My issue is that, when I connect wirelessly from a laptop to the WNDR3700 I am seeing at first a WINS server of 192.168.1.2 and once fully connected a DHCP server of 192.168.1.2. The default gateway is as intended and is 192.168.1.1.

I disconnected the RT-N16 and initially the WINS server was again 192.168.1.2 but once full connected all was as expected and windows reported all server and gateway addresses being 192.168.1.1.

Anyone can think of any reason why it seems that the WNDR passes the DHCP address on to the RT-N16?

As a side curiosity, can DHCP be disabled on the router which a wireless bridge connects to if it is connected to another router that has it enabled. A case where this would occur is if the wireless bridge connected to the RT-N16 instead. Could I still disable DHCP on that router since the WNDR which it connects to has DHCP enabled?

Thanks for any advice, I'm not an expert at networks...but I'm getting better.

 

[skyking]

You have too many radios going there. Turn off the radio in the RT-N16.

 

[GeekDrew]

If you are seeing that your DHCP server IP is that of the RT-N16, that means that the RT-N16 is seeing your device's DHCP request broadcast, and is responding by assigning an IP address.

Are you *absolutely certain* that the DHCP server is shut down on the RT-N16? Perhaps you could try this to test:

Unplug the RT-N16 from the WNDR3700.
Plug the laptop into the RT-N16.
See if it gets an IP address.
If so, then the RT-N16 is misconfigured. If not, then something odd is happening.

As to your question about whether DHCP needs to live on one particular device... DHCP can operate on any device that is addressed as a member of the same subnet. The method of connection (physical wire, wireless) is not important. The RT-N16 can provide DHCP services, or the WNDR can provide DHCP services, or the modem could (well... some modems can), or the WRT54GL could.

How is your modem connected to the WNDR? I *frequently* see modems using address 192.168.1.2.

Personally, I generally don't use 192.168.x.y for anything, ever, because too many devices are automatically programmed to assume that they can use certain IP addresses. I've found that using 172.16.x.y in residences and 10.x.y.z in businesses causes the least conflicts. But... I understand that the vast majority of folks will never see the issues that I've had to resolve. (Feel free to ignore this paragraph, I'm rambling.)

 

[GeekDrew]

You have too many radios going there. Turn off the radio in the RT-N16.

He doesn't say anywhere that the radio on the RT-N16 is enabled. I don't see how that could possibly make a difference with his current problem, anyway.

 

[PurdueRy]

He doesn't say anywhere that the radio on the RT-N16 is enabled. I don't see how that could possibly make a difference with his current problem, anyway.

You are correct Geekdrew, the only radios that are broadcasting are the dual radios on the WNDR3700.

That is an interesting idea about possible the modem being at 192.168.1.2, I had not thought of that. I don't believe that's the issue as I believe the motorola modem is at 192.168.100.1 but I can check on that.

It's possible that a setting is getting held over as I was looking at this after turning off the DHCP server. I did try to reboot the router to make sure it was fully refreshed. I'll try that test out to see if the RT-N16 still assigned an address even with DHCP disabled. I have Tomato USB installed on it so a bug is always possible.

The entire thing that started this is being in a apartment complex. Everybody and their mother has a 2.4GHz router and there were only a few channels that I got good wireless performance. I decided to jump to the 5GHz band in an attempt to "get away" from all the crowding. There looks like there is one 5GHz router in the area but given the channel spacing on the 5GHz band its much easier to stay away.

 

[GeekDrew]

Also, have you tried manually releasing (ipconfig /release) and renewing (ipconfig /renew) your IP address on your laptop (or whatever device is indicating that .2 is configuring it? I've seen numerous machines keep their last working IP address (regardless of DHCP config) when they're in the same subnet.

 

[JackMDS]

AFAIC it is a mistake to use the USB in Wireless Routers as servers.

If one wants Server get a Printer that is Network Ready, and an Enclosure that is Network Ready.

The USB Servers in the Routers are trouble.

They are the Best example to define YMMV.

Their is No way they can make them compatible with all the other 3rd party Hardware that is around and only adhere loosely to standards.

 

[PurdueRy]

AFAIC it is a mistake to use the USB in Wireless Routers as servers.

If one wants Server get a Printer that is Network Ready, and an Enclosure that is Network Ready.

The USB Servers in the Routers are trouble.

They are the Best example to define YMMV.

Their is No way they can make them compatible with all the other 3rd party Hardware that is around and only adhere loosely to standards.

I don't disagree with you but the USB functionality really doesn't have much to do with my issue. Only reason I changed from the RT-N16 to the WNDR3700 is because my wireless N performance was worse than wireless G and my only conclusion was because of interference issues in the apartment. Occasionally I could show internet speeds that were identical between the two, but it was hit and miss. So, in order to take advantage of true N speeds I was forced to go to 5GHz.

Personally, the print server in Tomato USB has been working great. I don't do critical printing from the laptop, that is done from the desktop, so I don't know if all the features of the printer work well through the server but for printing out receipts and web pages it works fine.

I also agree that its not the best way to have a NAS. But again, I just decided to hook up my wifes portable hard drive because otherwise she never uses it. This way she can grab the occasional file or save files to the hard drive. It may be slow but it works.

If we were doing heavy printing or heavy accessing of the NAS then I would probably be inclined to replace my printer and storage. But personally the Canon i960 and iP9000 are two of the best printers I have owned and the latter has no direct equivalent in a networked version, especially for the price I paid for it ($0).

 

[skyking]

I assumed you connected first time via the radio on the rt-n16. My bad.

 

[JackMDS]

PurdueRy, sorry that I was Not clear enough.

I believe that there is a strong probability that the RT, due to its USB server usage has some deviation from standards that contribute to the main issue of this thread.

 

[PurdueRy]

PurdueRy, sorry that I was Not clear enough.

I believe that there is a strong probability that the RT, due to its USB server usage has some deviation from standards that contribute to the main issue of this thread.

If the techniques outlined earlier don't fix the issue, I'll try deactivating all usb support. Personally, I am thinking it may just be an issue of a ipconfig /release like was stated earlier.

 

[GeekDrew]

PurdueRy, sorry that I was Not clear enough.

I believe that there is a strong probability that the RT, due to its USB server usage has some deviation from standards that contribute to the main issue of this thread.

If enabling USB support on *anything* requires a DHCP server service being enabled, somebody needs to be smacked upside the head.

 

[JackMDS]

If enabling USB support on *anything* requires a DHCP server service being enabled, somebody needs to be smacked upside the head.

Whether it is the USB or not on this specific case I do not know for sure because I did not work specifically with the Asus RT

However a little education is always Good for the ""What is the Best?"" Crowd. :hmm:

USB has a Master side (computer side), and client side (the USB peripherals).

The USB on stand-alone devices like Wireless Routers is a Master side.

There is a difference between USB Master on a computer, and USB Master on other devices.

The USB master uses parts of the computer's hardware, it counts on have CPU Memory etc.

When, it is on other device, the device must provide emulation for the USB client plug-in so it will be treat as though it is connected to a computer.

The 3rd party printer servers that suppose to turn any printer to a Network Printer (that are sold now for little money) were Not very successful. Because of poor USB Master emulation their level of compatibility was low, and in most cases they provided only very basic printing features (if at all).

The USB master on the Router is a little better because the Router has more of computer like hardware, but it is still not implemented, as it should.

The USB devices that are connected to the Router are suppose to be networked and are assigned with IP. I do not know what is the initial contribution of the Router in a case like this even if its DHCP is off.


BTW, if USB is always the same why some of the Routers with USB port indicate that the port is only good for printer and Not other USB devices, while others are only good for flash drives and nothing else?

 

[GeekDrew]

I agree with you, and I strongly discourage the use of such devices. That said, this has nothing to do with the OP's problem.

 

[PurdueRy]

Geekdrew you were correct it was simply windows holding over the previous gateway and server addresses from when both routers had their DHCP enabled.

Now I guess my question from this to better educate myself is how do multiple DHCP's work with one another? If I connect to a router with DHCP enabled and that is connected to another router with DHCP enabled which handles the IP address assignment?

 

[JackMDS]

You can Not run two DHCP servers on the same Network (subnet).

 

[GeekDrew]

You can Not run two DHCP servers on the same Network (subnet).

Yes, you can. It's just usually a bad idea to do so, and it'll cause a hell of a lot of problems if implemented incorrectly.

Now I guess my question from this to better educate myself is how do multiple DHCP's work with one another? If I connect to a router with DHCP enabled and that is connected to another router with DHCP enabled which handles the IP address assignment?

DHCP servers *generally* don't work together to provide services in any kind of coordinated fashion, and they absolutely will not without administrator configuration (doing so automatically would absolutely be a security breach).

When a computer interface comes online (that is to be DHCP managed), it sends a broadcast out, requesting configuration via DHCP. When multiple DHCP servers are present on the subnet, each server that receives the broadcast will act upon it (again, generally). The first response to be received by the client "wins". So, if the first server tells the client to begin using 192.168.1.100 and the second server tells the client to begin using 192.168.1.235, but the second response got to the client first, the client will begin using 192.168.1.235.

Why is that a problem? Take, for example, the subnet 192.168.1.0/24 (IPs 192.168.1.0 - 192.168.1.255). Say servers A and B are both configured so as to provide DHCP services for IP range 192.168.1.100 - 192.168.1.254. The order in which IP addresses are issued is *not* guaranteed (you can't configure the order of it issuing 100, 101, 102, 103, etc., versus 254, 253, 252, 251, 250, etc.). You'll therefore experience IP address assignment conflicts. The short version of multiple devices receiving the same IP address assignment is "things break". In reality, one or both devices will realize that they have an IP conflict. Whether they do anything about that or not is beyond the scope of this conversation - most will not do anything beyond perhaps alerting the user that there is an IP addressing problem. Communications will not work properly (data will be lost), and depending on what operating systems are used on what equipment, the network interface may be either restarted or disabled until the conflict is resolved. I think that we can agree that IP conflicts are not good.

Yes, I did say that multiple DHCP servers can be used on the same subnet. This is accomplished by splitting up the IP range that each DHCP server is permitted to issue. So, for this example, assume that server A is configured to use range 192.168.1.50 - 192.168.1.149, and server B is configured to use range 192.168.1.150 - 192.168.1.249. The client requests an address and both servers respond. It doesn't matter which response gets to the client first, because both servers are authoritative for the IP addresses that they are respectively assigned, and thus the client is guaranteed to be issued a valid IP address (valid as designated by DHCP standards in conjunction with the operating configuration).

Note that the number of DHCP clients that are permitted to use the subnet is now the maximum count of the smallest IP range -- given this configuration, you may have a maximum of no more than 100 devices on that subnet. If server A always responds faster than server B (and is thus effectively servicing all clients), it'll send a denial response faster than server B's response gets to the client, meaning that the client would effectively be unable to communicate on the subnet. The primary reason that this is done is for fault tolerance in corporate networks. That way, if server A falls flat on its ass, server B will still be online, and will be able to service clients.

The function of routing (or, in the case of most consumer devices, NAT) is completely independent of DHCP. Most routers come with DHCP services enabled on them because it's required for most networks, and it's the easiest way to get things working. That doesn't mean that DHCP needs to be, or even should be, running on the router. Any computer can be a DHCP server. You would still only want to have one router/NAT per subnet in a any consumer configuration (and most corporate networks). Thus, if you had multiple DHCP servers operating on the same subnet, they would all need to have the same router IP address configured for that DHCP range. Most DHCP servers have that capability; any DHCP server that does not permit administrative specification of the default gateway ought not to exist, but definitely should not be used in a multiple-DHCP-server configuration.

TLDR: Possible, but not advised.

 

[PurdueRy]

Yes, you can. It's just usually a bad idea to do so, and it'll cause a hell of a lot of problems if implemented incorrectly.



DHCP servers *generally* don't work together to provide services in any kind of coordinated fashion, and they absolutely will not without administrator configuration (doing so automatically would absolutely be a security breach).

When a computer interface comes online (that is to be DHCP managed), it sends a broadcast out, requesting configuration via DHCP. When multiple DHCP servers are present on the subnet, each server that receives the broadcast will act upon it (again, generally). The first response to be received by the client "wins". So, if the first server tells the client to begin using 192.168.1.100 and the second server tells the client to begin using 192.168.1.235, but the second response got to the client first, the client will begin using 192.168.1.235.

Why is that a problem? Take, for example, the subnet 192.168.1.0/24 (IPs 192.168.1.0 - 192.168.1.255). Say servers A and B are both configured so as to provide DHCP services for IP range 192.168.1.100 - 192.168.1.254. The order in which IP addresses are issued is *not* guaranteed (you can't configure the order of it issuing 100, 101, 102, 103, etc., versus 254, 253, 252, 251, 250, etc.). You'll therefore experience IP address assignment conflicts. The short version of multiple devices receiving the same IP address assignment is "things break". In reality, one or both devices will realize that they have an IP conflict. Whether they do anything about that or not is beyond the scope of this conversation - most will not do anything beyond perhaps alerting the user that there is an IP addressing problem. Communications will not work properly (data will be lost), and depending on what operating systems are used on what equipment, the network interface may be either restarted or disabled until the conflict is resolved. I think that we can agree that IP conflicts are not good.

Yes, I did say that multiple DHCP servers can be used on the same subnet. This is accomplished by splitting up the IP range that each DHCP server is permitted to issue. So, for this example, assume that server A is configured to use range 192.168.1.50 - 192.168.1.149, and server B is configured to use range 192.168.1.150 - 192.168.1.249. The client requests an address and both servers respond. It doesn't matter which response gets to the client first, because both servers are authoritative for the IP addresses that they are respectively assigned, and thus the client is guaranteed to be issued a valid IP address (valid as designated by DHCP standards in conjunction with the operating configuration).

Note that the number of DHCP clients that are permitted to use the subnet is now the maximum count of the smallest IP range -- given this configuration, you may have a maximum of no more than 100 devices on that subnet. If server A always responds faster than server B (and is thus effectively servicing all clients), it'll send a denial response faster than server B's response gets to the client, meaning that the client would effectively be unable to communicate on the subnet. The primary reason that this is done is for fault tolerance in corporate networks. That way, if server A falls flat on its ass, server B will still be online, and will be able to service clients.

The function of routing (or, in the case of most consumer devices, NAT) is completely independent of DHCP. Most routers come with DHCP services enabled on them because it's required for most networks, and it's the easiest way to get things working. That doesn't mean that DHCP needs to be, or even should be, running on the router. Any computer can be a DHCP server. You would still only want to have one router/NAT per subnet in a any consumer configuration (and most corporate networks). Thus, if you had multiple DHCP servers operating on the same subnet, they would all need to have the same router IP address configured for that DHCP range. Most DHCP servers have that capability; any DHCP server that does not permit administrative specification of the default gateway ought not to exist, but definitely should not be used in a multiple-DHCP-server configuration.

TLDR: Possible, but not advised.

I didn't quite follow the bolded portion but everything else was quite a good discussion. I really appreciate you taking the time to clarify DHCP operation for me. It can sometimes be tough to find a good explanation of a topic like this as it can often be either too simple a discussion or excessively detailed. Again, thanks a million.

I've noticed when something goes wrong with a network configuration, a computer will often be assigned what is seemingly a random ip address and then often doesn't have a gateway listed for its connection. I'll often see somethink like 156.934.23.45 listed as the IP address. Perhaps in this situations I should try to use the ipconfig /release. Often nothing is wrong with my configuration, I just have to reset the modem/router/connection and the issue clears up.

 

[RebateMonger]

I've noticed when something goes wrong with a network configuration, a computer will often be assigned what is seemingly a random ip address and then often doesn't have a gateway listed for its connection. I'll often see somethink like 156.934.23.45 listed as the IP address.

Since Windows 95, the default Windows setting for TCP/IP is that if an IP address is not manually configured or if the NIC doesn't find a DHCP server, then that interface will be given an IP address of the form 169.254.0.1 to 169.254.255.254 with Netmask 255.255.0.0.

Clients verify that their address is unique on the LAN. When a DHCP server is found, clients update their IP addresses automatically.This mechanism is called APIPA (Automatic Private IP Address). These AIPA addresses are all on the same subnet and can be used on a local network for communication between PCs.