Using lsof and fuser I can't find the process listening on a strange port
I've read other posts about finding the process ID and what's listening, but sadly couldn't get my issue solved. So, apologize if I missed some info about it.
Running netstat I found a port that I can't recognize: 35813
$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:35813 0.0.0.0:* LISTEN -
No PID information. Then ran lsof but shows no output about that port.
$ sudo lsof -i :35813
Also tried running just lsof -i
but nothing there seems suspicious.
This is the output with the TCP listening processes:
$ sudo lsof -Pni -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rpc.statd 520 statd 9u IPv4 11556 0t0 TCP *:56969 (LISTEN)
rpc.statd 520 statd 11u IPv6 11562 0t0 TCP *:46289 (LISTEN)
rpcbind 522 root 8u IPv4 11545 0t0 TCP *:111 (LISTEN)
rpcbind 522 root 11u IPv6 11548 0t0 TCP *:111 (LISTEN)
I also tried fuser
, but returned an empty output as well.
$ sudo fuser 35813/tcp
From a remote host inside the LAN, I can telnet the port:
$ telnet 192.168.0.16 35813
Trying 192.168.0.16...
Connected to 192.168.0.16.
Escape character is '^]'.
I can send a character, nothing happens. When I type the second character the connection is closed by the foreign host.
Finally I ran a grep
inside /etc/
trying to find something listening that port (a bit desperate) but couldn't find anything there.
The host is running OpenVPN (udp), lighttpd and ssh. Non of them use the port 35813. Any advice here? Many thanks in advance.
linux process port tcp
add a comment |
I've read other posts about finding the process ID and what's listening, but sadly couldn't get my issue solved. So, apologize if I missed some info about it.
Running netstat I found a port that I can't recognize: 35813
$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:35813 0.0.0.0:* LISTEN -
No PID information. Then ran lsof but shows no output about that port.
$ sudo lsof -i :35813
Also tried running just lsof -i
but nothing there seems suspicious.
This is the output with the TCP listening processes:
$ sudo lsof -Pni -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rpc.statd 520 statd 9u IPv4 11556 0t0 TCP *:56969 (LISTEN)
rpc.statd 520 statd 11u IPv6 11562 0t0 TCP *:46289 (LISTEN)
rpcbind 522 root 8u IPv4 11545 0t0 TCP *:111 (LISTEN)
rpcbind 522 root 11u IPv6 11548 0t0 TCP *:111 (LISTEN)
I also tried fuser
, but returned an empty output as well.
$ sudo fuser 35813/tcp
From a remote host inside the LAN, I can telnet the port:
$ telnet 192.168.0.16 35813
Trying 192.168.0.16...
Connected to 192.168.0.16.
Escape character is '^]'.
I can send a character, nothing happens. When I type the second character the connection is closed by the foreign host.
Finally I ran a grep
inside /etc/
trying to find something listening that port (a bit desperate) but couldn't find anything there.
The host is running OpenVPN (udp), lighttpd and ssh. Non of them use the port 35813. Any advice here? Many thanks in advance.
linux process port tcp
add a comment |
I've read other posts about finding the process ID and what's listening, but sadly couldn't get my issue solved. So, apologize if I missed some info about it.
Running netstat I found a port that I can't recognize: 35813
$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:35813 0.0.0.0:* LISTEN -
No PID information. Then ran lsof but shows no output about that port.
$ sudo lsof -i :35813
Also tried running just lsof -i
but nothing there seems suspicious.
This is the output with the TCP listening processes:
$ sudo lsof -Pni -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rpc.statd 520 statd 9u IPv4 11556 0t0 TCP *:56969 (LISTEN)
rpc.statd 520 statd 11u IPv6 11562 0t0 TCP *:46289 (LISTEN)
rpcbind 522 root 8u IPv4 11545 0t0 TCP *:111 (LISTEN)
rpcbind 522 root 11u IPv6 11548 0t0 TCP *:111 (LISTEN)
I also tried fuser
, but returned an empty output as well.
$ sudo fuser 35813/tcp
From a remote host inside the LAN, I can telnet the port:
$ telnet 192.168.0.16 35813
Trying 192.168.0.16...
Connected to 192.168.0.16.
Escape character is '^]'.
I can send a character, nothing happens. When I type the second character the connection is closed by the foreign host.
Finally I ran a grep
inside /etc/
trying to find something listening that port (a bit desperate) but couldn't find anything there.
The host is running OpenVPN (udp), lighttpd and ssh. Non of them use the port 35813. Any advice here? Many thanks in advance.
linux process port tcp
I've read other posts about finding the process ID and what's listening, but sadly couldn't get my issue solved. So, apologize if I missed some info about it.
Running netstat I found a port that I can't recognize: 35813
$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:35813 0.0.0.0:* LISTEN -
No PID information. Then ran lsof but shows no output about that port.
$ sudo lsof -i :35813
Also tried running just lsof -i
but nothing there seems suspicious.
This is the output with the TCP listening processes:
$ sudo lsof -Pni -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rpc.statd 520 statd 9u IPv4 11556 0t0 TCP *:56969 (LISTEN)
rpc.statd 520 statd 11u IPv6 11562 0t0 TCP *:46289 (LISTEN)
rpcbind 522 root 8u IPv4 11545 0t0 TCP *:111 (LISTEN)
rpcbind 522 root 11u IPv6 11548 0t0 TCP *:111 (LISTEN)
I also tried fuser
, but returned an empty output as well.
$ sudo fuser 35813/tcp
From a remote host inside the LAN, I can telnet the port:
$ telnet 192.168.0.16 35813
Trying 192.168.0.16...
Connected to 192.168.0.16.
Escape character is '^]'.
I can send a character, nothing happens. When I type the second character the connection is closed by the foreign host.
Finally I ran a grep
inside /etc/
trying to find something listening that port (a bit desperate) but couldn't find anything there.
The host is running OpenVPN (udp), lighttpd and ssh. Non of them use the port 35813. Any advice here? Many thanks in advance.
linux process port tcp
linux process port tcp
edited Feb 17 at 14:43
user2313067
2,1001911
2,1001911
asked Feb 17 at 13:38
jmoxjmox
33
33
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
As you describe it, your issue seems to be a UDP port that is a random number (therefore cannot get information about what is running on that port) and it is on a server? (Or NAS?)
You could try nmap -v -A -p {the port that you can't recognise} {the host IP}
.
If it returns "unknown" as a 'service running on port' then you can try and find out what are the services that are running usually on that port in Wikipedia.
Another solution is (if it is possible) to restart the server / NAS and see if it opens up again.
If it does (and you are running Linux (any)) you can close all UDP ports with commands which you can find on the internet by typing
how to disable all UDP connections on (version / distro) Linux.
Good luck!!
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
You may have helped the OP solve their problem, but I believe that this is a bad answer. Thenetstat
output at the beginning of the question clearly shows atcp
socket (port number 35813) inLISTEN
state (remember that UDP sockets are stateless), and thetelnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.
– Scott
Feb 17 at 17:11
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1406725%2fusing-lsof-and-fuser-i-cant-find-the-process-listening-on-a-strange-port%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As you describe it, your issue seems to be a UDP port that is a random number (therefore cannot get information about what is running on that port) and it is on a server? (Or NAS?)
You could try nmap -v -A -p {the port that you can't recognise} {the host IP}
.
If it returns "unknown" as a 'service running on port' then you can try and find out what are the services that are running usually on that port in Wikipedia.
Another solution is (if it is possible) to restart the server / NAS and see if it opens up again.
If it does (and you are running Linux (any)) you can close all UDP ports with commands which you can find on the internet by typing
how to disable all UDP connections on (version / distro) Linux.
Good luck!!
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
You may have helped the OP solve their problem, but I believe that this is a bad answer. Thenetstat
output at the beginning of the question clearly shows atcp
socket (port number 35813) inLISTEN
state (remember that UDP sockets are stateless), and thetelnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.
– Scott
Feb 17 at 17:11
add a comment |
As you describe it, your issue seems to be a UDP port that is a random number (therefore cannot get information about what is running on that port) and it is on a server? (Or NAS?)
You could try nmap -v -A -p {the port that you can't recognise} {the host IP}
.
If it returns "unknown" as a 'service running on port' then you can try and find out what are the services that are running usually on that port in Wikipedia.
Another solution is (if it is possible) to restart the server / NAS and see if it opens up again.
If it does (and you are running Linux (any)) you can close all UDP ports with commands which you can find on the internet by typing
how to disable all UDP connections on (version / distro) Linux.
Good luck!!
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
You may have helped the OP solve their problem, but I believe that this is a bad answer. Thenetstat
output at the beginning of the question clearly shows atcp
socket (port number 35813) inLISTEN
state (remember that UDP sockets are stateless), and thetelnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.
– Scott
Feb 17 at 17:11
add a comment |
As you describe it, your issue seems to be a UDP port that is a random number (therefore cannot get information about what is running on that port) and it is on a server? (Or NAS?)
You could try nmap -v -A -p {the port that you can't recognise} {the host IP}
.
If it returns "unknown" as a 'service running on port' then you can try and find out what are the services that are running usually on that port in Wikipedia.
Another solution is (if it is possible) to restart the server / NAS and see if it opens up again.
If it does (and you are running Linux (any)) you can close all UDP ports with commands which you can find on the internet by typing
how to disable all UDP connections on (version / distro) Linux.
Good luck!!
As you describe it, your issue seems to be a UDP port that is a random number (therefore cannot get information about what is running on that port) and it is on a server? (Or NAS?)
You could try nmap -v -A -p {the port that you can't recognise} {the host IP}
.
If it returns "unknown" as a 'service running on port' then you can try and find out what are the services that are running usually on that port in Wikipedia.
Another solution is (if it is possible) to restart the server / NAS and see if it opens up again.
If it does (and you are running Linux (any)) you can close all UDP ports with commands which you can find on the internet by typing
how to disable all UDP connections on (version / distro) Linux.
Good luck!!
answered Feb 17 at 14:36
TheCust0mTheCust0m
16
16
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
You may have helped the OP solve their problem, but I believe that this is a bad answer. Thenetstat
output at the beginning of the question clearly shows atcp
socket (port number 35813) inLISTEN
state (remember that UDP sockets are stateless), and thetelnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.
– Scott
Feb 17 at 17:11
add a comment |
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
You may have helped the OP solve their problem, but I believe that this is a bad answer. Thenetstat
output at the beginning of the question clearly shows atcp
socket (port number 35813) inLISTEN
state (remember that UDP sockets are stateless), and thetelnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.
– Scott
Feb 17 at 17:11
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
I am going to mark your answer as a solution. Nmap helped me to find out, thanks. It was the service nlockmgr of NFS, as I have a directory mounted over NFS, seems it opens a random tcp port. I disabled NFS and after restarting no strange port was listening. I enabled NFS mountpoint again and after restart another port was listening with nlockmgr running behind. I still don't understand why, because other similar hosts I have also mounting over NFS don't listen on random ports, but that would be out of the scope here. Thanks again.
– jmox
Feb 17 at 15:20
You may have helped the OP solve their problem, but I believe that this is a bad answer. The
netstat
output at the beginning of the question clearly shows a tcp
socket (port number 35813) in LISTEN
state (remember that UDP sockets are stateless), and the telnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.– Scott
Feb 17 at 17:11
You may have helped the OP solve their problem, but I believe that this is a bad answer. The
netstat
output at the beginning of the question clearly shows a tcp
socket (port number 35813) in LISTEN
state (remember that UDP sockets are stateless), and the telnet
experiment at the end of the question clearly shows that TCP port 35813 is accepting connections.– Scott
Feb 17 at 17:11
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1406725%2fusing-lsof-and-fuser-i-cant-find-the-process-listening-on-a-strange-port%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown