This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] tftp-hpa 5.0


On 10/4/2010 2:27 PM, Corinna Vinschen wrote:
> On Oct  4 13:13, Charles Wilson wrote:
>> Well, that's basically what happens already.  Incoming V4 packets get
>> turned into AI_V4MAPPED ones, always, IIRC -- when the socket was set
>> for both V4 and V6.
> 
> Erm... hang on.  A socket is created for only one domain/address family,
> AF_INET, AF_UNIX, AF_INET6.  There's no such thing as a socket supporting
> more than one address family or more than one socket type (stream/dgram).

I guess what I should have said, was that: when you open a socket for
AF_INET6, and you do NOT setsockopt IPV6_V6ONLY (on Vista+, where
dualstack sockets are the default), then you get v4-in-v6 mapping for
incoming v4 packets.

I forgot to mention that the problems I ran into were exposed only on
Vista+, XP- didn't display them: I believe the difference is that Vista
was where support for dualstack sockets was added -- so obviously this
issue wasn't a problem on pre-Vista.

I think xinetd's IPv6 support is written so that it doesn't need
dualstack support; it uses separate sockets for IPv6 and IPv4 (but on
Vista, with dualstack support, all the incoming IPv4 packets show up on
the IPv6 socket, as v4-in-v6, instead of on the IPv4 socket.  IIRC.)

Maybe xinetd should be modified so that IPv6 sockets are in IPV6_V6ONLY
-- but then any v4-in-v6 packets that some OTHER router wrapped might
get dropped?  What a pain.

>> This "unwrapping" is an application-level decision, IMO.  It just means
>> applications with (poorly coded) IPv6 support need additional fixin'
>> before it will work as expected on cygwin, in mixed-mode environments.
> 
> There's a difference between Linux and Windows, though, which affects
> the returned addresses from getaddrinfo, if the AI_V4MAPPED and AI_ALL
> flags are set.  In this case Linux returns V6 and V4 addresses, both
> formatted in their real address family.  Unless the given host has no V6
> address, in which case the V4 addresses are returned as V4inV6
> addresses.
> 
> On Windows, AI_V4MAPPED | AI_ALL always returns the V4 addresses as
> V4inV6 addresses.  I read the SUSv4 getaddrinfo man page, and from
> what I can tell both results should be ok:
> 
>   "If the AI_V4MAPPED flag is specified along with an ai_family of
>    AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
>    on finding no matching IPv6 addresses
>    [...]
>    If the AI_ALL flag is used with the AI_V4MAPPED flag, then
>    getaddrinfo() shall return all matching IPv6 and IPv4 addresses."
> 
> As you can see, the text does not specify that in the AI_V4MAPPED |
> AI_ALL case the IPv4 addresses should be returned in a given address
> family.  This *could* be changed in Cygwin to follow the Linux
> behaviour.
> 
> However, I have no idea if that affects your case, of course...

Right.  Well, inetd/xinetd appear to be working now.  So...I lean
towards not changing things that might break them. :-)

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]