Port AND IP specific applications - 'localhost' not working.

[David de Beer]

Hello.

I thought it might have something to do with the new TOUR (Transport Optional Upgrade Release) software we installed or us using tcp6 and not just old tcp anymore - but that was not the case.

An application is started to listen 'specifically' on certain ports. I am not sure how this is done.

Look at the following output from netstat -na

tcp 0 0 *.49393 *.* LISTEN
tcp 0 0 *.51585 *.* LISTEN
tcp 0 0 *.51592 *.* LISTEN

These 3 ports, as an example will connect to any address on the box, hence the * in front of the port # i.e. *.49393. So if the box had 10 IP's, it would allow all 10 + localhost to connect to the port.

Now this application doesn't look the same:

tcp 0 0 165.143.131.222.51110 *.* LISTEN
tcp 0 0 165.143.131.222.51111 *.* LISTEN
tcp 0 0 165.143.131.222.51112 *.* LISTEN

The application is only listening on 'specific IP' 165.143.131.222.

How does one set this behaviour?

We are unable to do a telnet localhost on this machine. Is there a way that we can change this - not on an application level? Is there no way to force localhost traffic through the .222 IP as source?

I have tried this behaviour on a number of other hosts, and it is consistent across HPUX11i.

netstat -rn output:
Routing tables
Destination Gateway Flags Refs Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 lo0 16424
165.143.131.222 165.143.131.222 UH 0 lan13 16424
165.143.130.0 165.143.131.222 U 2 lan13 1500
127.0.0.0 127.0.0.1 U 0 lo0 0
default 165.143.130.1 UG 0 lan13 0

/etc/hosts:
127.0.0.1 localhost loopback
165.143.131.222 host204

ifconfig lan13:
lan13: flags=843
inet 165.143.131.222 netmask fffffe00 broadcast 165.143.131.255

ifconfig lo0:
lo0: flags=849
inet 127.0.0.1 netmask ff000000

Regards,
David de Beer.

[harry d brown jr]

First step: install "lsof" : http://hpux.ee.ualberta.ca/hppd/hpux/Sysadmin/lsof-4.74/

Second, don't change localhost from 127.0.0.1, or a lot of crap will break.

third, an application can "listen" on a port by opening a socket and waiting for something to talk to it.

fourth, why do you want to do a telnet localhost ?? Can you talk to the application via the keyboard ??

fifth, you should not mess with localhost.

sixth, how do you have DNS configured? /etc/resolv.conf, /etc/nsswitch.conf, dns is at what release? (what `which named`)

seventh, use lsof to determine what applications are listening on those ports.

live free or die
harry d brown jr

[David de Beer]

>Second, don't change localhost from
>127.0.0.1, or a lot of crap will break.

I wasn't about to do that :)


> why do you want to do a telnet localhost
> ?? Can you talk to the
> application via the keyboard ??

Yes, we can talk to the app via the telnet, hence we want to be able to do a telnet localhost, if the app is running on the machine we are currently on instead of using the IP.

> sixth, how do you have DNS configured?

tcenh204:/) what /usr/sbin/named
/usr/sbin/named:
Copyright (c) 1986, 1989, 1990 The Regents of the University of California.
named 8.1.2 Fri Nov 21 05:54:28 GMT 2003 PHNE_30068

tcenh204:/) cat /etc/resolv.conf
domain telkom.co.za
nameserver 165.143.131.218
nameserver 165.148.21.94
nameserver 165.143.131.217

tcenh204:/) nslookup localhost
Using /etc/hosts on: tcenh204

looking up FILES
Name: localhost
Address: 127.0.0.1
Aliases: loopback

tcenh204:/) cat /etc/nsswitch.conf
passwd: files
group: files
hosts: files dns
services: files
networks: files
protocols: files
rpc: files
publickey: files
netgroup: files
automount: files
aliases: files

tcenh204:/) cat /etc/hosts
127.0.0.1 localhost loopback
165.143.131.222 tcenh204 tcenh204.telkom.co.za

[harry d brown jr]

You can modify your app to ALSO listen on localhost, or simply use the host name:

telnet host204 app_port_nbr

live free or die
harry d brown jr

[David de Beer]

I will speak to the Application Dev people, just wanted to understand if this is normal behaviour for HPUX11i or not, or perhaps just our enviroment (same patches on all deployed boxes).

It makes sense to me how it is currently, I was just wondering if there's some way to have localhost also answer the requests to the specific IP's and ports configured on the box. I've just never come across this before. Never seen two apache servers run on the same box with different IP's, both running on port 80. It makes sense, in a routing enviroment where all traffic goes out via different IP's and their interfaces. But what happens when you have two interfaces on the same network i.e. 200.1.1.1 and 200.1.1.2 and both of them run apache, both on port 80, and the default gateway is 200.1.1.1 Isn't all the answers then going to come from 200.1.1.1 to the clients?

Thanks,
David.

[harry d brown jr]

...if this is normal behaviour for HPUX11i or not, ...

It's the behaviour of ALL OS's, not just HP-ux.

... apache servers run on the same box with different IP's, both running on port 80 ...

quite slick, eh?

A PORT is tied to an IP. Thus if a server had 10 IP's, it could have 10 applications listening on a port, say port 80. (we talk about threads)

IP:port

live free or die
harry d brown jr

[rick jones · Accepted solution]

In and of themselves, port numbers and IP addresses are distinct. Applications can call bind() to bind an endpoint (accessed via a socket) to a specific IP address and/or port. The specifics are in the manpage for bind. If it is done before the listen() and accept() calls, those become the destination IP address and port number. If it is done before the connect() call, those will be the source IP address and/or port number.

The proper way to get an application to bind to a specific IP address or port is for it to make the apropriate bind() call(s). If the application does not, you are pretty much stuck, unless you are willing and able to write a "shim" library to intercept the bind() (and perhaps other socket calls) to get the binding as you want it.

As for how one tells a specific application to bind to specific IP/port numbers that is, well, application specific.

It would be far better to get the application source fixed.

[David de Beer]

Nothing to be done on a system level, application specific process.