[ reply-to set, please honour it (or change it to tech@), don't
crosspost between misc and tech. ]

On 2010/05/30 04:26, Casey Allen Shobe wrote:
quoted text
> So apparently the E___ commands exist for IPv6 compatibility.  The
> tnftp that Debian packages uses EPSV/EPRT per default.  It supposedly
> falls back to PASV/PORT if the server fails to recognize the command,
> but I don't really know any ancient FTP servers to test with.  `ftp`
> in OpenBSD 4.6 happily used PASV/PORT.  In OpenBSD 4.7, `ftp` now

Not sure why you're seeing problems now, but this hasn't changed
in years. ftp in OpenBSD 4.6 used EPSV by default too. And it does
still fallback from EPSV to PASV (you can see this with e.g. 
ftp -d ftp://ftp.symantec.com/).

quoted text
> fallback to PASV/PORT.  However, since the FTP server is not saying
> "500 OMG WTF IS THAT", the client never falls back, and instead just
> times out eventually.  Apparently our firewall device is too old and
> doesn't support NAT properly with the new E___ commands, and we're

Yes, that's exactly it. For pkg_add I suggest switching to an http
mirror (or you could set FETCH_CMD="ftp -E" for pkg_add, but switching
to http is more straightforward).

Does anyone know the rationale for setting epsv4 = 1 by default?

On the one hand it's useful to know that the network connection is
broken, but that's about the only advantage I can see, on the other
hand if you're actually trying to fetch files (especially from a
*server* behind a broken nat device that's not under your control)
it's a real pain.

We mirror distfiles for some ports because of this...