[ITP] tftp-hpa 5.0

[Charles Wilson]

On 10/4/2010 12:02 PM, Corinna Vinschen wrote:
> On Oct  4 11:10, Charles Wilson wrote:
>> It's not so much *cygwin*, as *windows*.  If a socket is opened to
>> listen for both IPv4 and IPv6 packets, then *all* received packets will
>> appear as IPv6 ones -- IPv4 ones will show up "wrapped" as
>> ::ffff::71.15.23.51 or something.
> 
> Which functions are you talking about?  getpeername?  accept?  readfrom?
> getaddrinfo?  All of them?

I'm going by memory here...and I don't recall. :-(   I'll have to review
those threads.

> If so, we could do something about that by massaging the returned
> addresses from V4-in-V6 into plain V4 addresses.  Since the memory
> region used for V6 can easily contain a V4 address, we don't have
> to change any memory allocation or so, just tweak the content of the
> sockaddr structure.  Well, except in case AI_V4MAPPED is specified
> in getaddrinfo...

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.

Properly written applications, which claim to support V6, should handle
V4-in-V6 seamlessly.  If they don't, then it's an application bug.

If they can only deal with true IPv4 packages or "full" IPv6
packets...then they should open two sockets, one in V6-only mode on the
V6 address, and one in V4-only mode on the V4 address -- and even then
it would fail if some other router mapped an incoming IPv4 as V4-in-V6
before it ever gets to your computer!

It's easier, really, to just FIX the application to fully support V6,
including the V4 variations.  Otherwise, it doesn't REALLY support V6,
now does it?

> Well, that's not exactly just a Windows problem.  Any interface can at
> any time return more than one V4 and more than one V6 address.  Not only
> my Windows machines, but also my Linux machines typically have at least
> one V4 and two V6 addresses.  A tool which doesn't grok this is just
> horribly broken.  I guess the age of inetutils really shows...

Bingo.  I always say that "inetutils doesn't support IPv6" but that's
not entirely true.  inetd kinda sorta does, but badly -- which is where
I ran into all of these issue; the patch is...large.  The "regular"
servers like rshd etc don't seem to support IPv6 at all.

That's the main reason I'm (slowly) trying to use more modern
implementations of the regular servers, which DO support IPv6.  Like
tftp-hpa.

>> I was thinking of borrowing a page from openssh's privsep 'sshd' user,
>> and using a -config script to create a 'tftpd' user.
...
>> If anything fails, tftpd logs the error and exits; it never attempts to
>> "keep going" without dropping privileges -- unless you told it to remain
>> in a privileged state via '-u root'.
> 
> Sounds good to me.

:-)

>> Anyway, once I've done that, I'll send|post the updated tarballs before
>> beginning to address IPv6 et al -- which might not happen for a week or two.
> 
> Just to let you know, I'll be mostly unavailable for the next five weeks
> starting this weekend.  If there's something required in terms of the
> aforementioned V4inV6 problem, the time to do something is either now or
> late in November.

If there is an actual problem that requires cygwin changes (which I
doubt) then Nov is soon enough.

I don't think it's a good idea for cygwin to automatically  "unwrap"
v4-in-v6, because we have no (easy) way of knowing if the packet
ACTUALLY arrived on the v6 interface because somebody ELSE wrapped it
before it reached our ethernet port, or if Windows wrapped something
that arrived on the v4 interface, and then presented it to cygwin AS IF
it arrived on the V6 interface, as a V4-in-V6 packet.

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.

You're right, tho, that this is /not/ a cygwin-specific problem; there
are many multi-homed and mixed-mode unix systems...

--
Chuck