Danny Mayer wrote:
> Wolfgang S. Rupprecht wrote:
>
>>[EMAIL PROTECTED] (Danny Mayer) writes:
>>
>>>This definitely shows a problem. Either there is something else running
>>>and binding to the wildcard IPv6 socket or there is a problem with
>>>support of IPv6.
>>
>>I've seen this problem with other programs under linux's ipv6. The
>>problem is that the linux stack unlike the Kame stack used in BSD's
>>uses mapped ipv4 addresses in ipv6. If one opens up a whildcard
>>listening socket for both the ipv4 stack (with AF_INET) and then again
>>for the ipv6 stack (with AF_INET6), one ends up trying to open the v4
>>port a second time through the mapped-address. The trick is to only
>>open up the AF_INET6 socket - it implies the ipv4 mapping.
>>
>>I imagine this effects any daemon listening on an ipv6 socket in
>>linux.
>>
>>-wolfgang
>
>
> This is probably what is causing the problems in bug #135 and bug #716.
> If this true then it's a bug in the IP stack of the O/S and should get
> fixed. IPv6 addresses are unrelated to IPv4 addresses and should never
> be mixed. Such attempts to do so cause many problems and this is just
> one symptom. You should get your O/S vendor to address the problem. I
> will try one thing and try and bind the IPv6 wildcard address (::) first
> and then the IPv4 address (0.0.0.0) but I don't know if that will really
> make a difference if this is badly architected by the O/S.
does this look any different when you do a :
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,.....
before any binding to that local port?
G!
uwe
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
