[krbdev.mit.edu #6019] Add signal to force KDC to check for changed interfaces
Ken Raeburn via RT
rt-comment at krbdev.mit.edu
Wed Jul 9 13:50:59 EDT 2008
On Jul 8, 2008, at 17:55, Nicolas Williams via RT wrote:
> Or use a PF_ROUTE socket?
I'm not terribly familiar with using PF_ROUTE sockets, but from a
quick read of the route(4) man page, I suspect it would work, and
would be more automated than having to send a signal.
At least one ipsec package doesn't visibly update the routing table
when tunnels are brought up and new addresses assigned -- but then, it
doesn't make the new addresses visible either, so we're no worse off.
Maybe lxs should check with Apple and see if they have a reason for
not doing it this way. I'd guess it probably was easier than trying
to untangle our network handling callback setup, but I'd have no such
excuse. :)
A minor problem with the Apple patch -- or any revised one that still
uses closedown_network/setup_network -- is that it'll discard any
pending requests over UDP that have been queued by the kernel but not
yet read by the KDC. I'd have to dig into the code to figure out if
open TCP connections get closed, get serviced, or get ignored; my
guess is they'll get closed.
Discarded UDP packets would get retransmitted by the client; that's
okay. Closed TCP connections won't be retried by an MIT client (to
the same KDC address), but usually UDP will be getting tried as well,
unless we've got too much PAC data. Ignored TCP connections would
waste resources on the KDC. It would be nicer to only close down the
listening sockets where we no longer own the address, so we never stop
listening, but...
I'm also not 100% sure that closedown_network does a full cleanup.
getcurtime should probably become an inline function in one of the
headers, it's a trivial enough thing and we should avoid the code
duplication.
More information about the krb5-bugs
mailing list