Better interface detection? (was Re: krb5kdc crashes)

[Nicolas Williams]

On Mon, Apr 08, 2002 at 02:49:01PM -0400, Ken Raeburn wrote:
> Nicolas Williams <Nicolas.Williams at ubsw.com> writes:
> > Can this work? It sure sounds like the code would be simpler.
> 
> It would work on systems where recvmsg lets you get the appropriate
> control information.  But under IRIX 6.5, for example, you only get
> the old 4.3BSD-style "access rights", which AFAIK is only useful for
> passing a file descriptor between processes.  So, assuming we need to
> support KDCs on IRIX (not necessarily a given, although MIT is still
> using IRIX 6.5 on some systems) or other such systems, we could only
> do what you suggest as an optimization.

Hey, I don't need Irix support :)

More seriously, both approaches could be implemented. Then on systems
like Irix you get stuck with the old behaviour and on systems where this
can work your KDC will adapt to new interfaces coming up no problem and
will be able to start even when only lo0 is up. OTOH, I'm not asking for
this, I just thought that here was an opportunity to cut out a bunch of
code in your KDC.

[IPv6 stuff cut out]

I don't think you should drop IPv4-only support anytime soon, but
whatever you can do in the IPv6 sphere will be most welcome, no doubt.

> Does the "control data" interface support for IPv4 let you control the
> sending address when writing, or just get the recipient address when
> reading?

IIRC, no and if it did it wouldn't be highly portable.


> Ken


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.