• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Making a port listen

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How do you make a port to listen on HP Unix on 11.11.

Whenever we request a port to be open for firewall we need to test it long before its actually be used for. We don't have permissions to create an instance and start it which would make the port listen.

Any ideas?
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

Don't have permission to create an instance of what?

"netcat" (also called "nc") is the Swiss Army knife of TCP/IP; it's trivial to use it to simulate all kinds of network servers and clients. Check it out -- it's probably the solution to whatever your problem is.
 
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Strictly speaking ports don't listen, it is just an id number. Not a physical object in your machine.

Ernest's idea is terrific if you don't have access to another program that requests a port from the OS. Just be careful and don't keep it running in listen mode without locking it down. No need to have a ready made back door on your system.

Your question is vague, but my first thought was that on some systems if an application wants to bind to a well known port, it needs root access. If that is the case, bind to a port over 1024.
 
Mike Barley
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Ernest and Rusty. However netcat is not recognized in HP unix. It says 'sh: netcat: not found.'
We usually have situations when we request our networking team to open a port in firewall to be used for a new application between appservers and webservers, server and client, etc as all our ports are blocked by firewall. When the network team opens we are supposed to test it, but we can't untill the port is listening - which means when i do netstat -an | grep <port#> it should show up.

As far as I know it could only show as listening whenever we have some instance using that port - for example a websphere clone using that port. But we can't configure a websphere clone to use that port or make changes untill the maintainance time as this is production environment.

Other than that is there any other way than to create websphere clone to make that port in listen mode. we can simply type in httpd.conf of IBM HTTP webserver and type in Listen <port #> and restart the webserver and it would do it, but we got the app servers and web servers on different servers.
 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Once the firewall is opened, that means you *can* talk to the port, i.e. you have permission. But that does not mean that anything is listening to the port or will do anything if you talk to it.

If you don't have netcat, you can just use telnet and specify the port


If you get "connection refused" than the port is blocked from Unix. If you get nothing, you have a connection, but you then have to follow whatever protocol you are using.

For example, you can usually do

and get something back such as




 
Mike Barley
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Telnet won't work, I was told that it should work only when i do the netstat -an | grep <port> it should give you the output like this:

$ netstat -an | grep 8531
tcp 0 0 *.8531 *.* LISTEN

The other thing is i need to telnet from the server/client where i requested the port to be opened. That server/client could be any other unix server, my windows local machine etc.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Netcat isn't usually provided with the base OS, but one reason you can't find it is because it's often installed with the name "nc".

"netstat -ln" can tell you if a port is listening for traffic. And yes, this does mean a "port" object has been created for the traffic to be routed to, so some of the OS component display utilities will also show it, but netstat is your best bet.

A port can be listening in one of 2 ways:

1. Directly. A (server) app opens the port and listens on it.

2. Indirectly. The super-server (inetd/xinetd) may dynamically fire up services on receipt of traffic on that port. Technically I suppose that the super-server could dissect any unclaimed traffic, but I was working on a Linux box the other day and it looked like the super-server was opening ports just like a server app would, so a netstat -ln would see that as well.

Super-servers aren't used as much as they were when hardware was less powerful. They permit servers to fire on demand, but the price is slower initial connection.

Telnet can respond in one of 3 ways to traffic.

1. If the server is a text-based service, you'll usually get back a text response. Text-based services include HTTP servers, mailers, FTP (the command port) and many of the older Internet services where portability was important and being able to walk/debug the protocols via manual telnet input was useful.

2. If the service provides a binary service, your telnet client will usually hang waiting for the proper input. Sometimes it may spit binary gunk back at you. Unless you're really, really good at typing in binary, the main value here is that you know you're connecting to something.

3. If there is no available service on the selected machine/port, telnet will return an "unable to connect" message.

Telnet's prime virtue for network debugging is that it can tell you not only that the target machine is listening, but that there's nothing blocking traffic (e.g. a firewall).
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic