Better interface detection? (was Re: krb5kdc crashes)

Ken Raeburn raeburn at MIT.EDU
Mon Apr 8 14:49:01 EDT 2002


Nicolas Williams <Nicolas.Williams at ubsw.com> writes:

> 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.

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.

On the bright side, I suspect all the IPv6 support would be able to
use this approach.  Actually, IIRC, the IPv6 socket API extensions let
you control the source address when sending, so we'd only need one UDP
socket for IPv6, period.  And if we use IPv4-mapped IPv6 addresses,
that one socket would handle IPv4 traffic as well.  But systems vary
in how well they support that, I think.  The BIND folks ran into lots
of portability issues there; their docs may still be the best write-up
of the problems.

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

Ken



More information about the Kerberos mailing list