Arnt Gulbrandsen <[email protected]> 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
