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:127.0.0.1 > > 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. joe
