Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

2007-12-25 Thread Florian Weimer
* Colin Watson:

 [*] 1.0.0.0 isn't even a valid IP address, is it?

 Depends on the situation. You wouldn't want to give a host that
 address,

Why not?  Subnet zero is no longer reserved.  The whole /8 is currently
not assigned, but that's a different matter.

 but it might be quite reasonable to have an A record resolve to that IP
 address for the purpose of naming the network. The resolver isn't in a
 position to distinguish those cases, IMO.

Fully agreed.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

2007-12-25 Thread Colin Watson
On Tue, Dec 25, 2007 at 07:40:24PM +0100, Florian Weimer wrote:
 * Colin Watson:
[Please don't remove attributions. Vincent Lefevre wrote this bit.]
  [*] 1.0.0.0 isn't even a valid IP address, is it?
 
  Depends on the situation. You wouldn't want to give a host that
  address,
 
 Why not?  Subnet zero is no longer reserved.  The whole /8 is currently
 not assigned, but that's a different matter.

I was under the impression that it was conventional even if not required
to reserve host zero in a given subnet to identify the network itself,
to avoid confusion of networks with hosts.

Still, we're in agreement on the basic implementation issue so it
doesn't matter too much.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

2007-12-25 Thread Vincent Lefevre
On 2007-12-25 21:38:48 +, Colin Watson wrote:
 I was under the impression that it was conventional even if not required
 to reserve host zero in a given subnet to identify the network itself,
 to avoid confusion of networks with hosts.

I thought for this reason 1.0.0.0 could be detected as not corresponding
to a hostname.

Now, if I understand correctly (but I've only partial information
about the problem), the problem occurs with IPv6 DNS requests only,
but 1.0.0.0 is an IPv4 address. So, I suppose that there could be
a workaround.

And FYI, there doesn't seem to be any firmware upgrade for the router
(D-Link DSL-924).

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Processed: Re: Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

2007-12-24 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 reassign 457472 glibc
Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0
Bug reassigned from package `openssh-client' to `glibc'.

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

2007-12-24 Thread Colin Watson
On Mon, Dec 24, 2007 at 03:07:51PM +0100, Vincent Lefevre wrote:
 On 2007-12-24 10:49:32 +, Colin Watson wrote:
  I can't tell for sure from your strace (in future, use -s 1024 so that
  buffers passed to system calls aren't truncated to quite such a short
  length), but your diagnosis sounds right, and it doesn't sound like
  OpenSSH is the appropriate place for a deployed workaround. Reassigning
  to glibc where the resolver is implemented.
 
 OK, I didn't know what OpenSSH used for DNS resolving. As different
 software behaves differently, this is rather confusing. After more
 tests, it seems that Iceweasel has the same problem, though other
 users (as seen in discussions on web forums) reported that Firefox
 worked (but perhaps they have disabled IPv6 in Firefox or somewhere
 else). Some users reported the same problem with apt-get with Debian
 and Ubuntu[*]. So, this probably comes from glibc (I suppose that
 not all software does IPv6 DNS requests).

Indeed, OpenSSH just uses getaddrinfo, which is the newer generation of
library support for name resolution. I imagine, though, that the
relevant fact is that it does an  query and gets garbage back.

  However, in your particular case, setting 'AddressFamily inet' in
  /etc/ssh/ssh_config should work around the problem just for ssh.
 
 The solution I chose was to disable the DNS forwarding service of
 the D-Link router; but this meant I had to fill the /etc/resolv.conf
 manually (I thought the router would provide the DNS servers of the
 ISP instead of the local 192.168.1.1, but after running pump, the
 /etc/resolv.conf file is left unchanged). However, the consequence
 is that Windows machines (which don't support IPv6, thus are not
 affected by the bug of the router) can no longer use the router's
 DNS service either.

Have you considered asking your router vendor for a firmware upgrade? It
sounds like a straightforward bug in their DNS implementation.

Thanks,

-- 
Colin Watson   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

2007-12-24 Thread Vincent Lefevre
On 2007-12-24 21:48:18 +, Colin Watson wrote:
 On Mon, Dec 24, 2007 at 05:01:28PM +0100, Pierre Habouzit wrote:
  On Mon, Dec 24, 2007 at 03:37:39PM +, Colin Watson wrote:
   Have you considered asking your router vendor for a firmware
   upgrade? It sounds like a straightforward bug in their DNS
   implementation.

I'll try to see if there's one.

Well it looks like it's not a Debian problem at all right ?
 
 No idea; I reassigned it in case there was a possible workaround (e.g.
 detecting and discarding the bogus replies).

In particular if the bug in the router is widespread, a workaround
(if possible[*]) would be a good idea. Even if there are other ways
to deal with this bug, most users affected by it would wonder what
the problem is (as seen in discussions found by a search on Google).
For instance, Firefox just says:

  The connection has timed out
  The server at host is taking too long to respond.
*   The site could be temporarily unavailable or too busy. Try again
in a few moments.
*   If you are unable to load any pages, check your computer's network
connection.
*   If your computer or network is protected by a firewall or proxy,
make sure that Iceweasel is permitted to access the Web.

It may be a bit difficult for the average user to solve the problem,
due to lack of information. And if he has tried under Windows (where
the bug doesn't appear), he would think that Windows is working and
Linux isn't. :(

[*] 1.0.0.0 isn't even a valid IP address, is it?

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]