[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