Better interface detection? (was Re: krb5kdc crashes)

Nicolas Williams Nicolas.Williams at ubsw.com
Mon Apr 8 14:11:09 EDT 2002


Interesting thought along the lines of what you say:

 - have one UDP socket bound to INADDR_ANY
 - when a packet arrives on the INADDR_ANY UDP socket get the
   destination address (recvmsg()), create a new UDP socket and bind it
   to the destination address of the packet received
 - add new sockets created this way to the list of sockets to poll on
 - don't bother with SIOCIFCONF

The basic idea being: if you can receive packets sent to a given IP
address, you can bind a socket to that IP address, taking advantage of
the fact that the INADDR_ANY socket will act as the default destination
for packets received on interfaces to which the KDC is not bound.

Can this work? It sure sounds like the code would be simpler.

Nico

On Tue, Apr 02, 2002 at 10:50:22PM -0500, Ken Raeburn wrote:
> jfanonymouswindows at yahoo.com writes:
> > krb5kdc: no sockets set up?
> > krb5kdc: no sockets set up?
> 
> Well, that's not exactly a crash, it's decided it doesn't have any
> network interfaces and quietly exits.  But that's quibbling....
> 
> The question is, why does it decide it has no network interfaces?
> When you try to start it up, *is* the machine configured to have
> network addresses at the time?  (As opposed to being, say, a
> disconnected laptop.)  If so, somehow the SIOCGIFCONF support in
> kdc/network.c (and nearly-identical code in lib/krb5/os/localaddr.c)
> is failing to detect them.  It does filter out the loopback interface
> ("lo", 127.0.0.1) and interfaces that are not configured "up", and it
> only handles IPv4, not IPv6.
> 
> Because of the way the IPv4 socket interface works, the KDC needs to
> find all of the local IPv4 network addresses and listen on them.  One
> listening socket with a wildcard address won't do, because on a
> multi-homed machine, the KDC can't control the IP address used to send
> the response, and if that address is wrong, the response will be
> discarded.  I've got some other ideas in mind I might try coding up
> for future releases, such as using the wildcard socket to determine
> when the machine has acquired an address the KDC didn't know about
> when it started up, as a signal that it should re-check the local
> addresses.  It still can't usefully process the packet it got *if* the
> machine has multiple addresses, but if it has only one, it's probably
> a safe bet that that one address is the one the client is expecting
> the KDC to use.
> 
> Ken
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos
-- 
-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.




More information about the Kerberos mailing list