[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug? kadmind binds only to IPv6 addresses, if IPv6 is enabled




"Torsten Kurbad" <torsten@tk-webart.de> writes:

> From: "Love" <lha@stacken.kth.se>
>
>>> It seems that kadmind binds to *:749/tcp, which causes an IPv6 enabled
> linux
>>> host to insist that 749/tcp is already bound even for IPv4.
>>> By starting kadmind with the -d option it will report that the socket is
>>> already bound for af=2.
>
>> last time I checked, linux also answered ipv6 used ipv4 mapped addresses
>> for ipv6 sockets, so, didn't it just work ?
>
> Nope, if it would simply work, I wouldn't complain... ;o)

What is the failure ? I assume that you can connect to ipv4:749/tcp but you
get some kind of failure.

> IMO, to have the functionality you mentioned above, it is necessary to
> activate IPv6 in IPv4 tunneling, which isn't always what you want...

Mapped v4 addresses is something else, its storing mapped v4 adresses
inside v6 address only internally on the host. The idea was that all
applications should just need to to something like this on the source-code

	s/sockaddr_in/sockaddr_in6/g;s/AF_INET/AF_INET6/g

and it should work with both ipv4 and ipv6.

mapped v4 addresses are on the form: "::ffff:N.N.N.N"

>>> Would it be difficult to enhance kadmind in that way?
>
>> Not really, just need to share code between kadmind and kdc, but isn't it
>> easier to start kadmind from inetd ?
>> [excerpt from documentation]
>
> This was the first thing I tried and it didn't work either (that's why I
> even came to the idea to let kadmind run on its own). We use xinetd, btw.
> The thing is that xinetd (like the "old fashioned" inetd) only allows a weak
> kind of access control to certain services, i.e. does allow/deny access for
> requests from different subnets, but doesn't really care about binding to
> special addresses. And if you can only specify a port on an IPv6 enabled
> machine, this port is bound for all types of addresses. So, the same problem
> again...
>
> Apart from that, running services from xinetd is not really what I prefer,
> since we have amanda running as a backup service on the same machine and if
> something kills xinetd, amanda dies with it... ;o(
>
> Also, you cited a phrase that caught my attention (although nobody explains
> it any further) that it's not recommended to start kadmind from inetd.
>
> Eventually, I'll try to write a patch for kadmind on my own and suggest it
> here for further discussions...

Try this:

	echo 1 > /proc/sys/net/ipv6/bindv6only

setting

#ifdef IPV6_V6ONLY
{
     int on = 0;
     setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on) 
}
#endif

on all sockets might also work just fine.

Love

PGP signature