Very Computer

Hi,

I have a session in a machine with solaris 8

# telnet localhost 80
Trying 127.0.0.1...

# telnet name_machine 80
Trying 10.95.5.34...
Connected to name_machine.
Escape character is '^]'.

Why  is it OK when I use the name of the machine and not with localhost?

When I use #telnet localhost port, where port isn't 80 it's OK again.
It seems to depend on the port, but on the other hand it's is OK with
the same port and using the name of the machine

Regards,

Adolfo

It may well be that whatever is listening on port 80 (apache?) is only
listening on some of the machine's addresses, & in particular not the
localhost address.

If it is apache, then you can find some info on this from
http://httpd.apache.org/docs/2.0/bind.html

--tim

When you do this, packets are going to be coming from 127.0.0.1.

Does the httpd that's listening on port 80 do reverse DNS lookups
before accepting the connection, and if so, can it to a reverse
lookup of 127.0.0.1?  Or, if you have tcp_wrappers or similar
installed around the httpd, does it look up by hostname?

Quote:> # telnet name_machine 80
> Trying 10.95.5.34...
> Connected to name_machine.
> Escape character is '^]'.

> Why  is it OK when I use the name of the machine and not with localhost?

> When I use #telnet localhost port, where port isn't 80 it's OK again.
> It seems to depend on the port, but on the other hand it's is OK with
> the same port and using the name of the machine

Probably a DNS problem, which would explain why different ports behave
differently:  they have different behavior with regard to DNS, since
that behavior is application-specific.

   - Logan

It isn't apache
I have the same problem with #telnet 127.0.0.1 80 , so DNS must be OK,
mustn't be?

Logan

Could you explain this me again?. I don't understand what I should do

 >Does the httpd that's listening on port 80 do reverse DNS lookups
 > before accepting the connection, and if so, can it to a reverse
 > lookup of 127.0.0.1?  Or, if you have tcp_wrappers or similar
 > installed around the httpd, does it look up by hostname?

Logan Shaw escribi:

Quote:> I have a session in a machine with solaris 8

> # telnet localhost 80
> Trying 127.0.0.1...

Sounds like whatever is listening on port 80 won't talk back to
localhost (consult its logfiles) or its shielded off by a firewall.

--
Groetjes, Peter

.\\ PGP/GPG key: http://www.catslair.org/pubkey.asc

That "telnet localhost 80" and "telnet 127.0.0.1 80" both behave
the same only means that the telnet program is able to translate
"localhost" into "127.0.0.1".  But at the other end of the TCP
stream, whatever is listening on port 80 may be trying to
translate 127.0.0.1 to its corresponding hostname and failing
to do so.

Just because some DNS queries are working doesn't mean all of them
will.  In fact, DNS is a distributed system, so it's almost never
the case that all possible DNS queries work.  (There is always
some server that's down.)

If you have dig installed, can you do "dig -x 127.0.0.1"?  Does
it return quickly and say that "1.0.0.127.in-addr.arpa." is an
"IN PTR" to "localhost".  Does it sit and wait?

Another possibility besides this being a DNS problem is that
you have some sort of firewall issue.  Are you running a firewall
or packet filter on the machine?

   - Logan

Sounds more like the OP's /etc/inet/hosts and/or /etc/inet/ipnodes file(s)
do not have an entry for "localhost".

Would anybody configure a firewall on lo0?  Perhaps....

It must have an entry for localhost - it's resolving it to
the proper address in the telnet attempt above.

JS

Aaaaarrrggg, you're right.

Quote:> It must have an entry for localhost - it's resolving it to
> the proper address in the telnet attempt above.

That and the fact that the OP already stated to have tried "telnet
127.0.0.1 ...".

--
Groetjes, Peter

.\\ PGP/GPG key: http://www.catslair.org/pubkey.asc

Not necessarily.

If localhost were missing from /etc/hosts (et al) and present in DNS,
then "localhost" could still be resolved into 127.0.0.1.  But if the
corresponding reverse record were missing, or if there were improper
delegation and the DNS server that the client uses were trying to do
a recursive query against a non existent server to find the H in
"1.0.0.127.in-addr.arpa IN PTR H", then that would explain the
server* in this situation.

Hmm, that is assuming that "telnet foo 80" (where foo is something
that resolves to a local address that is not 127.0.0.1) doesn't
show up as being from 127.0.0.1 to the thing that accepts the
connection on port 80.  I'm not positive I understand how the
source address for the TCP packets is chosen when you connect to
something that's obviously a local address.  It could conceivably
choose either the local address or 127.0.0.1 as the source address
since either would work...

   - Logan

run this command:

       netstat -an | grep "\.80 "

If it shows something like:

       10.95.5.34.80       *.*       0      0 49152      0 LISTEN

your web server is bounded to this IP address and won't answer
on localhost.

Yeah, but in that case, shouldn't they get

        # telnet localhost 80
        Trying 127.0.0.1
        telnet: Unable to connect to remote host: Connection refused

instead of just a hang?

   - Logan

Hmm, upon further thought, I've realized this is probably not correct
if the original poster accurately reported what they saw, i.e. that
it hangs after the "Trying 127.0.0.1..." line.

If it were an issue of DNS on the server side of the TCP socket,
then it should print this:

        $ telnet localhost 80
        Trying 127.0.0.1...
        Connected to localhost.

and THEN hang.  In other words, I'm fairly sure that there is no way
for Apache to know the remote end's address until it calls accept(),
and at that point the TCP stack will finish setting up the connection.
And if Apache doesn't know the address, it can't be having a DNS
problem doing a reverse lookup on the address, because you can't do
the lookup without knowing the address, obviously.

So I think this is probably not a DNS problem.  Which leaves something
like packet filtering or routing.

And since they said it behaves differently for different ports, that
would pretty much rule out routing as a possible problem.

   - Logan

Logan Shaw escribi:

Although we were in the main server, in the end we restart the
aplicacion and now we don't have the problem.

Thanks,

Adolfo