Using lsof and fuser I can't find the process listening on a strange port












0















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.










share|improve this question





























    0















    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.










    share|improve this question



























      0












      0








      0








      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.










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 17 at 14:43









      user2313067

      2,1001911




      2,1001911










      asked Feb 17 at 13:38









      jmoxjmox

      33




      33






















          1 Answer
          1






          active

          oldest

          votes


















          0














          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!!






          share|improve this answer
























          • 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












          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          0














          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!!






          share|improve this answer
























          • 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
















          0














          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!!






          share|improve this answer
























          • 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














          0












          0








          0







          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!!






          share|improve this answer













          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!!







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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.  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



















          • 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

















          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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

          Mangá

          Eduardo VII do Reino Unido