Discussion:
ftp diags with multiple peer addresses, some unreachable
(too old to reply)
Ignatios Souvatzis
2012-06-28 16:51:21 UTC
Permalink
Hi,

a discussion on tech-user@ has reminded me that the same perceived problem
came up at least one time in the past.

When a peer name resolves to multiple addresses, and the first one
in the list is not reachable, ftp tries the next one until the list
is exausted or a connection succeeds. (This can happen often on
the current network, when servers have e.g. one or multiple IPv6
and IPv4 address records in DNS, and the client doesn't have
connectivity for one of the address families).

This works fine per default - here's output from my test setup:

# ftp ftp.netbsd.org
Trying 2001:470:1f05:3d::21:21 ...
ftp: Can't connect to `2001:470:1f05:3d::21:21': No route to host
Trying 199.233.217.249:21 ...
Connected to ftp.netbsd.org.
220 ftp.NetBSD.org FTP server (NetBSD-ftpd 20100320) ready.
Name (ftp.netbsd.org:root):

However, if the verbose mode is switched off (e.g. through the
ftp -V ftp.netbsd.org
ftp: Can't connect to `2001:470:1f05:3d::21:21': No route to host
Name (ftp.netbsd.org:ignatios):

Note that we get an error message and then a prompt for auth
information. How are those related? The "Name" prompt is not for
the address mentioned on the line above!

My proposal is to suppress, in terse mode only, the error message
*for EHOSTUNREACH* if we still have more addresses to try.

The verbose output from above doesn't change (in fact, it's from my
patched ftp); the terse one changes to this:

# ftp -V ftp.netbsd.org
Name (ftp.netbsd.org:root):

I do not think that other errors should be suppressed in any case.
The exception for EHOSTUNREACH is IMO warranted because it's a
condition that will show up often; and the user has explicitly asked
to not be bothered with non-fatal messages.

Diff is appended.

Regards,
-is
Greg Troxel
2012-06-28 17:00:42 UTC
Permalink
Post by Ignatios Souvatzis
My proposal is to suppress, in terse mode only, the error message
*for EHOSTUNREACH* if we still have more addresses to try.
That's arguably reasonable, and an improvement on the current behavior.
But I'd go one step further and say:

in terse mode, suppress all EHOSTUNREACH
if after looping through all addresses, print
"ftp: Can't connect to any address of <name>"

That said, I don't object to your change - I think it's progress.
Darren Reed
2012-06-29 02:23:24 UTC
Permalink
Post by Greg Troxel
Post by Ignatios Souvatzis
My proposal is to suppress, in terse mode only, the error message
*for EHOSTUNREACH* if we still have more addresses to try.
That's arguably reasonable, and an improvement on the current behavior.
in terse mode, suppress all EHOSTUNREACH
if after looping through all addresses, print
"ftp: Can't connect to any address of <name>"
That said, I don't object to your change - I think it's progress.
What he said.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Matthew Mondor
2012-06-29 03:31:40 UTC
Permalink
On Thu, 28 Jun 2012 18:51:21 +0200
Post by Ignatios Souvatzis
Connected to ftp.netbsd.org.
I agree about supressing unnecessary error messages in terse mode.

Would it be acceptable to still show this line in non-verbose, mode, but
also including the address, i.e.:

Connected to ftp.netbsd.org (199.233.217.249:21)

Then it doesn't matter which addresses it tried, or how many, but on
successful connection we know where we managed to finally connect,
before the authentication prompt... To me this is not verbose
information but informational.

Thanks,
--
Matt

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2012-06-29 09:56:53 UTC
Permalink
Hi,
Post by Matthew Mondor
On Thu, 28 Jun 2012 18:51:21 +0200
Post by Ignatios Souvatzis
Connected to ftp.netbsd.org.
I agree about supressing unnecessary error messages in terse mode.
Would it be acceptable to still show this line in non-verbose, mode, but
Connected to ftp.netbsd.org (199.233.217.249:21)
Then it doesn't matter which addresses it tried, or how many, but on
successful connection we know where we managed to finally connect,
before the authentication prompt...
Hm, this would be a seperate change - pretty easy and self-contained, btw.

However, this should only happen for interactive mode, not for
fetch-URL mode, else it looks like this:

# ftp -V ftp://ftp.netbsd.org/robots.txt
Connected to ftp.netbsd.org (2001:470:1f05:3d::21:21).
#
Post by Matthew Mondor
To me this is not verbose information but informational.
Agreed.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Matthew Mondor
2012-06-29 10:22:20 UTC
Permalink
On Fri, 29 Jun 2012 11:56:53 +0200
Post by Ignatios Souvatzis
Post by Matthew Mondor
Would it be acceptable to still show this line in non-verbose, mode, but
Connected to ftp.netbsd.org (199.233.217.249:21)
Then it doesn't matter which addresses it tried, or how many, but on
successful connection we know where we managed to finally connect,
before the authentication prompt...
Hm, this would be a seperate change - pretty easy and self-contained, btw.
However, this should only happen for interactive mode, not for
# ftp -V ftp://ftp.netbsd.org/robots.txt
Connected to ftp.netbsd.org (2001:470:1f05:3d::21:21).
I agree that it only matters for interactive mode.

True it's also a separate change, I overlooked and had the impression
that your patch suppressed that line with -V in interactive mode, but
that's actually the current behaviour. I realized then that having the
address would also be useful, especially if suppressing the "Trying"
messages. I could file a PR with a patch for this if you prefer.

Thanks,
--
Matt

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...