Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (8.12.9) with ESMTP id m69Hoto4008860; Wed, 9 Jul 2008 13:50:55 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m69HoUAs023616; Wed, 9 Jul 2008 13:50:31 -0400 (EDT) Received: from NOME-KING.MIT.EDU (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m69HoUE8004136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Jul 2008 13:50:30 -0400 (EDT) Message-ID: <7AD214DA-5517-49FE-80C0-C37279E29981@mit.edu> From: Ken Raeburn To: rt-comment@krbdev.mit.edu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: [krbdev.mit.edu #6019] Add signal to force KDC to check for changed interfaces MIME-Version: 1.0 (Apple Message framework v926) Date: Wed, 9 Jul 2008 13:50:29 -0400 References: X-Mailer: Apple Mail (2.926) X-Scanned-BY: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1760 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.