Arnt Gulbrandsen <arnt@???> wrote:

> This sounds like a bug; 182.etc is not inside the DHCP server's network. A linux box should not end up with an IP address outside the DHCP server's address/netmask, even if the DHCP server is returning nonsense. The linux box should either get a usable address or no address at all.

Actually, there is no such restriction for DHCP.
The DHCP server can be elsewhere as long as there is a relay agent on the client's network. About the only requirements are that there is a relay agent (aka helper) within the client's broadcast domain, and that there is unicast IP routing between the client's subnet and server. Oh yes, and there is no requirement that a DHCP server or relay agent be on a router.

However if you meant router rather than DHCP server, then you are sort-of correct. However, I'm not sure how robust most DHCP clients are in this respect. I suspect many work on the basis that the DHCP server admin should know what he's doing !

But being pedantic, it is valid to have an IP address without any router within that subnet. On that basis, it would actually be wrong for a DHCP client to refuse to take an address because it doesn't have a valid router - it may be what the network admin actually wants. For example, at work we have a "backend" network for communication between servers - but it does not have any external access by design, and therefore there should be no routers specified in DHCP offers.