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.
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.
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.
"Computer science is no more about computers than astronomy is about telescopes" - Edsger Dijkstra
Joined: Jul 17, 2008
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.
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).
Customer surveys are for companies who didn't pay proper attention to begin with.