On 26/05/14(Mon) 08:03, Kenneth Westerback wrote: > [...] > > dhclient used to create such routes but that was removed as useless so > I'm not sure why we want/need to add them back. I'm not a routing > table guru so perhaps this is different in some way.
We want it back to be able to tell if an address is configured locally by using the routing table. But to be able to trust the routing table we must ensure that every local address is associated to a route entry. This diff is a step in this direction. > Extra RTM_NEWADDR messages may cause problems for dhclient, since it > will exit on what it thinks are attempts to add addresses to an > interface. Not sure if RTM_NEWADDR makes sense if all you are doing is > adding a route. That's a really good question, and I don't have the answer. Originally RTM_NEWADDR was generated when a route to prefix was added for a new address. It was simple: 1 address -> 1 route + message. Later on the logic in netinet/in.c has been modified to be able to setup an address without adding a route to prefix, if this route was already present for example. That's what happens if you have two addresses on the same subnet configured on your machine. With this, we now have: 1 address -> maybe 1 route + message. With this diff we always create a route, but maybe a second one if it is the first address of a subnet. So we have: 1 address -> 1 or 2 route + messages. > I'm in the middle of some other stuff but I certainly want to test > this to make sure there are no bad side effects on dhclient. No rush, let me know when you're done :) Martin
