how to listen a port use nc command

SUSE Linux Enterprise Server SLES Configure-Administer
1

On Suse Linux Enterprise Server 12 SP2, use nc command to listen port 8088
nc -l -p 8088
but meet below message:
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46DdhklnrStUuvzC] [-i interval] [-P proxy_username] [-p source_port]
[-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_protocol]
[-x proxy_address[:port]] [hostname] [port[s]]

So may I ask what’s the right command to run listen a port using netcat so that can use telnet to test the connectivity between servers.

2

Hi patrikyu,

have you tried “nc -l 8088”? That’s what is given at least in my version of the man page:

[QUOTE]CLIENT/SERVER MODEL
It is quite simple to build a very basic client/server model using nc. On one console, start nc listening on a specific port for a connection. For example:

       $ nc -l 1234

 nc is now listening on port 1234 for a connection.[/QUOTE]

“-p” is for the source port, when running “nc” in client mode.

Regards,
J

3

There are different versions of netcat, even within SLES, so be sure to
check the manpage. -p means source port in your version, meaning the port
netcat would use if connecting to a client (vs. acting like a server); in
your version, the -p is not desirable because -l implies that a port must
be specified.

I’ve had to do some work on RHEL/CentOS boxes this past week and the
confusion there is even worse; within the same distro, which are supposed
to be on the same version, with the same packages installed, some of them
do not support the -z (useful for testing a port’s openness from the
client side) option is there on about 2/3 of the boxes, but not on the
last third. Also, SLES has historically had a ‘netcat’ command, where now
I think they have ‘nc’ which is what most other distros have. Humbug.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

4

[QUOTE=jmozdzen;54509]Hi patrikyu,

have you tried “nc -l 8088”? That’s what is given at least in my version of the man page:

“-p” is for the source port, when running “nc” in client mode.

Regards,
J[/QUOTE]
Unfortunately, I put nc - l 8080 then press enter button, the command window is still waiting for keyboard input, so I use ctrl+C to break. Any suggestion? This OS is crazing, centos/redhat is much more easy use.

5

[QUOTE=ab;54512]There are different versions of netcat, even within SLES, so be sure to
check the manpage. -p means source port in your version, meaning the port
netcat would use if connecting to a client (vs. acting like a server); in
your version, the -p is not desirable because -l implies that a port must
be specified.

I’ve had to do some work on RHEL/CentOS boxes this past week and the
confusion there is even worse; within the same distro, which are supposed
to be on the same version, with the same packages installed, some of them
do not support the -z (useful for testing a port’s openness from the
client side) option is there on about 2/3 of the boxes, but not on the
last third. Also, SLES has historically had a ‘netcat’ command, where now
I think they have ‘nc’ which is what most other distros have. Humbug.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.[/QUOTE]

In my understanding the port of client is not need to specified, I just need listen the port which on current server but not remote server, am I correct?

6

Hi patrickyu,

pardon me, what else were you expecting? You’ve started nc in listening mode, so it’s listening and waiting for input?

Don’t complain, act. Or go and read the manuals, learn, understand, and use the tools like you would with any other distro. “nc” isn’t specific to this distro and the general behavior is the same, for RH-based distros, for SUSE-based distros, for other distros. As it is with admins, some complain about distros, while the root cause is in front of the terminal. (Not that the distros wouldn’t be very different sometimes, even up to the point that one distro looks insane, while others seem to handle that specific issue just right. But this “nc” case doesn’t belong to this category.)

Regards,
J

7

On 09/27/2018 02:34 AM, patrickyu wrote:[color=blue]

In my understanding the port of client is not need to specified, I just
need listen the port which on current server but not remote server, am I
correct?[/color]

Perhaps it would be useful if you told us what your end goal, or business
case, is. Everything is working as you have told it to, though apparently
you think it should be doing something else. The problem is that you do
not understand the command, and what you have told us so far has led us to
help you run the command in one way, when what you really want may be to
run it in another way. Give us the business case, or end goal, and we’ll
do our best to help you.

netcat is useful for listening, like a server, or connecting to a port,
like a client. The thread so far has been about the server options, but
when you run it as a server you should not expect it to do anything until
connected-to by a client, yet you seem to think something should show up
there . Like any other service (web, SSH, etc.), once running nothing
happens until a client connects.

If you want to run in client mode, then the command is a little different,
but it depends on your end goal. Are you testing firewalls by ensuring a
TCP conection can be setup? Are you transferring data in some way? Are
you wanting to send e-mail via SMTP? These are all client-ish things
netcat can do, but you need to tell us or, per your initial example, we’ll
assume you want to do server things.

Back to your initial question, you may specify the source port, but most
TCP clients (browsers, SSH, etc.) do not get into that level of detail,
and most firewalls care less about sources than they do targets, so
focusing on the source port on the client side is probably not where you
should start when first learning how to use the netcat command.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

8

hi ab

The purpose is ‘testing firewalls by ensuring aTCP conection can be setup’ from serverA to serverB, both installed Suse Linux 12SP2. Tried to run telnet on serverA:telnet serverB port# but failed, so I try to run nc command on serverB to listen a specific port. Client is SSH.

9

Hi patrickyu,

[QUOTE=patrickyu;54644]hi ab

The purpose is ‘testing firewalls by ensuring aTCP conection can be setup’ from serverA to serverB, both installed Suse Linux 12SP2. Tried to run telnet on serverA:telnet serverB port# but failed, so I try to run nc command on serverB to listen a specific port. Client is SSH.[/QUOTE]

then "nc -l ", run on serverB, is indeed what you’re looking for. That “nc” instance will remain active until you stop/kill it and listens for traffic on the specified port. Running “telnet serverB portnumber” on serverA will connect to that nc instance and anything you then type in the telnet client, shoud be visible on stdout of the nc (therefore in the shell session where you invoked “nc”).

Once you’re satisfied with the test results, simply stop the nc instance via Ctrl-C.

Regards,
J

10

On 09/28/2018 04:04 AM, patrickyu wrote:[color=blue]

hi ab

The purpose is ‘-testing firewalls by ensuring aTCP conection can be
setup-’ from serverA to serverB, both installed Suse Linux 12SP2. Tried
to run telnet on serverA:telnet serverB port# but failed, so I try to[/color]

Telnet is an outdated insecure abomination; it’s there on the system, but
you’re better off using netcat since it does a lot more (telnet client is
just an insecure client similar to rsh or ftp), is binary safe with data,
and can also do what telnet does (there’s a switch to emulate it).

First some assumptions:

I assume you are acting in the role of the OS and network guy, not
necessarily running the desired “service” (listening server process) at
this time. In other words, the boxes are built, the firewalls are in
place, and you want to know that once you have service A on box/server A
running, will client application B on box B be able to access it with all
firewalls current in place?

In order to do that test you need something to listen on the correct port,
as you know, and I am assuming that service is not yet in place. If it is
in place, and listening, then this first part of setting up netcat as a
listener is not needed, but using netcat as the listener is one of my
favorite things for firewall testing because it usually bows app owners’
minds, as they only think about having their specific application in place
for this testing, and of course that’s not true when you are only testing
up through layer four (4) (Transport) of the OSI model.

To make netcat listen on SLES 12 we already know the command:

nc -k -l 12345

Note that I added the ‘-k’ in there so netcat will not immediately stop
listening when the first client disconnects. This may be useful to you so
you can test one client, disconnect, test another, disconnect, etc. It
also means that, to end the server side, you cannot just make one
connection from the client and disconnect, so it is much more service-like
because normally services do not stop when the first client disconnects.
Note that you cannot connect multiple clients at once (in parallel) but
you can do so serially (one after another).

Also note that, unless you use a port lower than 1024, you do not need
‘root’ privileges to do this. SSH in particular uses TCP 22, so if you
are doing SSH stuff, test with sudo (or ‘root’ directly) or you will get
errors when you run the command above:

sudo nc -k -l 12345

Before you go to the client side, you can also verify that the server side
is listening with the ‘ss’ command:

/usr/sbin/ss -plaento | grep :12345

You should see something like this:

LISTEN     0      1            *:12345                    *:*
users:(("nc",pid=19871,fd=3)) uid:1000 ino:4411763 sk:5e <->

Note that it shows the process name (‘nc’), the PID (19871), the UID of
the user running it (1000 in my case), and of course the fact it is
LISTENing and on TCP 12345. If you do not see this then nothing else will
work.

Another check you can do is of the host-based (vs. network-based)
firewall, and ‘iptables’ is probably the easiest way to do this, if not
with ‘iptables-save’:

sudo /usr/sbin/iptables -nvL
sudo /usr/sbin/iptables -nvL | grep 12345
sudo /usr/sbin/iptables-save | grep 12345

From this you may get a couple things; if the first command returns very
little, but maybe three (3) blocks each indicating the default policy is
to ACCEPT, then the host-based firewall is wide open (not recommended)
which means it will not interfere with anything. From the second commands
if you get lines that show specific allowances for TCP 12345 then that is
good, meaning your host-based firewall is configured, but it is set to
allow access to TCP 12345. Examples follow:

#wide open firewall:
Chain INPUT (policy ACCEPT 21M packets, 9102M bytes)
pkts bytes target     prot opt in     out     source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 23M packets, 9310M bytes)
pkts bytes target     prot opt in     out     source
destination



#Configured firewall lines:
17198  877K LOG        tcp  --  *      *       0.0.0.0/0
0.0.0.0/0            limit: avg 3/min burst 5 tcp dpt:12345flags:
0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP "
109K  128M ACCEPT     tcp  --  *      *       0.0.0.0/0
0.0.0.0/0            tcp dpt:12345



#or from iptables-save:

-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 12345
--tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP "
--log-tcp-options --log-ip-options
-A input_ext -p tcp -m tcp --dport 12345 -j ACCEPT

If none of this appears on your system, you may have the default firewall
in place which is focused on security first, meaning it will block access
to everything unless you tel it otherwise as any firewall should.
Configure that with ‘/sbin/yast firewall’ to allow access to whatever port

Finally your server side is ready, netcat is listening (or maybe SSH is
directly), and your host-based firewall on that side is setup. At this
point you can test with netcat as a client (not telnet) because netcat is
going to make fewer bad assumptions about your connection, and even has an
option simply to tell you if the TCP connection works or not:

nc -zv server.ip.address.here 12345

If this returns something like this, then you are golden:

Connection to 127.0.0.1 12345 port [tcp/italk] succeeded!

As shown above, you can even do this locally (on the server itself) to
ensure that your netcat listener is working without any host-based or
network-based firewall interference. If so, then any new problems are
firewall issues and you can troubleshoot those without worrying about
applications.

You can also use netcat to send data to the server side by removing the
'‘z’ portion:

nc -v server.ip.address.here 12345

Any lines you type, followed by [Enter], will be sent to the server side,
and you will see them there. Also, because TCP is bidirectional, you can
type on either the server OR client side and have the lines, followed by
[Enter] (a newline), show up on the other side, so this is a cheap/free
way to chat between two systems.

netcat can do a lot more, as it is a very good TCP client, like trasnfer
data of any type (binary data, which telnet cannot do), and that is a
useful trick, e.g. if you want to copy files from here to there, even
non-text files.
[color=blue]

run nc command on serverB to listen a specific port. Client is SSH.[/color]

If your client is SSH, then your service should also be SSH, and I am
surprised you are not just using that on the server side since it is
present by default on SLES and just needs to be turned on.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

11

In other words, the boxes are built, the firewalls are in
place, and you want to know that once you have service A on box/server A
running, will client application B on box B be able to access it with all
firewalls current in place?

Exactly is the purpose. I have applied sudo permission and will let you know the result if sudo nc -k -l port#. Currenty, if not use sudo, no error will return but just wait for input, thank you.

12

On 09/29/2018 09:54 PM, patrickyu wrote:[color=blue]

-In other words, the boxes are built, the firewalls are in
place, and you want to know that once you have service A on box/server A
running, will client application B on box B be able to access it with
all
firewalls current in place?

Exactly is the purpose. I have applied sudo permission and will let you
know the result if sudo nc -k -l port#. Currenty, if not use sudo, no
error will return but just wait for input, thank you.[/color]

Be sure to read the rest of my post; I know it’s long, but what you are
stating here is not necessarily an error, particularly if the port is 1024
or higher. If you think it should do something, then you still are not
understanding the way that TCP communications work, but going through my
post should give you more tests to verify what you would like to verify.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

13

Yes I noted the port# above 1024 need sudo and indeed i tired to listen 8088. Now, I have sudo permission, but nc -k -l 8088 or nc -l 8088 still does not work, I attach the screen shot you can see that it looks like the command is not complete.
My steps:

  1. sudo su -
  2. enter
  3. nc -k -l 8088
  4. enter
14

Hi patrickyu,

looks perfectly fine. If you re-read our answers, you might notice that we’re trying to explain to you that the program is running. In other words, it’s not that the command “still does not work”, but still does it’s work. It’s waiting for connections from the remote - how should it do that if it terminates? And since it hasn’t terminated (yet), you see no new prompt.

Regards,
J

15

BIG Thanks!!! Totally my misunderstanding at beginning about how netcat work, learn from this test.

16

Hi patrickyu,

good to see it now works for you.

Just for clarification and others reading this thread:

Yes I noted the port# above 1024 need sudo

it’s just the other way around - you’ll need root permissions to open ports below 1024. (You likely got fooled by nc not returning to the prompt.) And since you’re actually running nc against a high port number: Don’t run it as root (not even via sudo), restrict yourself to such cases where this is actually needed, just for security’s sake.

Regards,
J

17

got it, yes you are right nc not return prompt puzzled me several days. BTW:8080 is planned to be used for a application which is still under construction, the server connectivity test is needed at this moment. Thank you again!