apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c
Date Mon, 10 Dec 2007 20:34:11 GMT
On Mon, Dec 10, 2007 at 07:55:47PM +0000, Colm MacCarthaigh wrote:
> On Mon, Dec 10, 2007 at 12:57:18PM -0600, William A. Rowe, Jr. wrote:
> > Now apr has provided a tuple of ip address, family and port that
> > cannot be reconstituted by APR.  So, for example, where we have
> > to create a connection to the very same host/family on a different
> > port, it becomes impossible.
> O.k., so the scenario is ;
> 	1. Host application listens on :: , accepts incoming socket
> 	   from ::ffff:
> 	2. Host application resolves the IP into a text format.
> 	   (calls getnameinfo or whatever)
> 	3. Host application takes that text format and turns 
> 	   it back into a sockaddr. (calls getaddrinfo or whatever)
> 	4. Connects to that IP.
> Why would it ever do steps 2 and 3?

Thank you very much Colm for decoding Bill for me.  

This is for FTP EPRT/EPSV support I'd guess.  I can imagine how it gets 
broken by the ::ffff:-stripping in apr_sockaddr_ip_getbuf since you have 
to send the serialized (family, address) on the wire for one of those 
newfangled FTP commands.

So yes Bill, you'd need to add a variant of apr_sockaddr_ip_getbuf to 
make this work and I also agree the ::ffff:-stripping should never 
really have been done there in the first place (but now must retained 
for compatibility, I suppose).

Either way, trying to work around that with an APR resolver hack seems 
completely wrong, -1, it will propagate v4-mapped IPv6 addresses when 
none are necessary, that may very well break/confuse other callers.


View raw message