ken Powell - Sun Microsystem wrote: > James Carlson wrote: >> The latter would make it possible for you to set PARAM_IGNORE_LIST so >> that the DHCP client would not use that option. (It's not a fix, but >> it'd be a useful work-around, just in case there's someone out there >> with a DHCP server that gives out bogus netmasks that aren't "obvious.") >> > > Just ignoring the netmask would still fail at the hotel I was at. > The default netmask for address 192.168.7.216 is 255.255.255.0. > I needed a netmask of 255.255.252.0 to reach the router.
It'd be better than what we have now. I believe what happens now is that we set the netmask and then either fail (because the ioctl fails) or explode later when you try to change it to be right. At least with an ignore option, you could potentially move this one thing to the user's hands. (I guess that adds a third thing to my list: if netmask is ignored, then the abandon logic needs to ignore it.) I wonder how Windows manages to work on that network. If they're given a next hop address for a default router, and that address is off of the local network, do they just ARP for it on spec? If so -- and it's the only way I can see this working -- that's bizarre, and would likely be hard to emulate. Maybe the best we could do would be to detect that the default router address we've been given is off of the local network specified, and -- within some constraints -- just widen out the configured netmask so that the router becomes reachable. It's certainly a "wrong" thing to do, but far less wrong than teaching ARP to ignore subnets. I've often wanted a "you and the horse you rode in on" option for a return message to peers that violate the protocols this badly. This situation would be a good application. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
