ncat only works in certain scenarios












2















I tried using ncat (a “much-improved reimplementation of netcat”) to chat with a friend (and ultimately want to send a large file, but I know I can get that working once I get chat to work).



We both have Windows.



On my end I typed:



ncat -l 3333


On his end I had him type:



ncat [my public IP] 3333


Nothing happened on my end, while his completed with "Ncat: ." and returned to the prompt.



I couldn't figure out what to do to fix this, so I decided, while he's busy, I'll test this out on two of my own laptops (one with Windows, the other with Linux, not sure if it should matter).



I found the same results ("Ncat: ." then back to prompt) only when I issued



ncat -l 3333


from Linux and



ncat [my public IP] 3333


from Windows.



The only scenario in which the chat/file-transfer did work was when I listened from Windows and did ncat [my public IP] 3333 from Linux.



Any ideas why this is happening, and what I can do to fix it?










share|improve this question















migrated from stackoverflow.com Mar 5 '13 at 7:36


This question came from our site for professional and enthusiast programmers.
















  • You did not tell wether it's working or not. At the moment, you don't like the blinking cursor. That's all you've told. Please give us more information of what works and what doesn't. And I suggest you portforwarding, if the connection could not be established.

    – Peter
    Mar 5 '13 at 7:50













  • @Peter: Read it again. He’s saying that the client process exits immediately upon being started.

    – Scott
    Mar 5 '13 at 20:53











  • Emil: Have you tried -v (and -vv and -vvv)? Do you have a sniffer (e.g., ethereal, Wireshark, tcpdump, …)? Can you see what is happening on the wire?

    – Scott
    Mar 5 '13 at 20:54











  • yes, I have Wireshark. I can try taking a look, but it is a little overwhelming, and I'm not sure what to look for. I took my first Routing/networking class last semester, so I'm new to this. I'll check though and see if anything looks...::ahem:: familiar

    – Emil
    Mar 6 '13 at 3:18


















2















I tried using ncat (a “much-improved reimplementation of netcat”) to chat with a friend (and ultimately want to send a large file, but I know I can get that working once I get chat to work).



We both have Windows.



On my end I typed:



ncat -l 3333


On his end I had him type:



ncat [my public IP] 3333


Nothing happened on my end, while his completed with "Ncat: ." and returned to the prompt.



I couldn't figure out what to do to fix this, so I decided, while he's busy, I'll test this out on two of my own laptops (one with Windows, the other with Linux, not sure if it should matter).



I found the same results ("Ncat: ." then back to prompt) only when I issued



ncat -l 3333


from Linux and



ncat [my public IP] 3333


from Windows.



The only scenario in which the chat/file-transfer did work was when I listened from Windows and did ncat [my public IP] 3333 from Linux.



Any ideas why this is happening, and what I can do to fix it?










share|improve this question















migrated from stackoverflow.com Mar 5 '13 at 7:36


This question came from our site for professional and enthusiast programmers.
















  • You did not tell wether it's working or not. At the moment, you don't like the blinking cursor. That's all you've told. Please give us more information of what works and what doesn't. And I suggest you portforwarding, if the connection could not be established.

    – Peter
    Mar 5 '13 at 7:50













  • @Peter: Read it again. He’s saying that the client process exits immediately upon being started.

    – Scott
    Mar 5 '13 at 20:53











  • Emil: Have you tried -v (and -vv and -vvv)? Do you have a sniffer (e.g., ethereal, Wireshark, tcpdump, …)? Can you see what is happening on the wire?

    – Scott
    Mar 5 '13 at 20:54











  • yes, I have Wireshark. I can try taking a look, but it is a little overwhelming, and I'm not sure what to look for. I took my first Routing/networking class last semester, so I'm new to this. I'll check though and see if anything looks...::ahem:: familiar

    – Emil
    Mar 6 '13 at 3:18
















2












2








2








I tried using ncat (a “much-improved reimplementation of netcat”) to chat with a friend (and ultimately want to send a large file, but I know I can get that working once I get chat to work).



We both have Windows.



On my end I typed:



ncat -l 3333


On his end I had him type:



ncat [my public IP] 3333


Nothing happened on my end, while his completed with "Ncat: ." and returned to the prompt.



I couldn't figure out what to do to fix this, so I decided, while he's busy, I'll test this out on two of my own laptops (one with Windows, the other with Linux, not sure if it should matter).



I found the same results ("Ncat: ." then back to prompt) only when I issued



ncat -l 3333


from Linux and



ncat [my public IP] 3333


from Windows.



The only scenario in which the chat/file-transfer did work was when I listened from Windows and did ncat [my public IP] 3333 from Linux.



Any ideas why this is happening, and what I can do to fix it?










share|improve this question
















I tried using ncat (a “much-improved reimplementation of netcat”) to chat with a friend (and ultimately want to send a large file, but I know I can get that working once I get chat to work).



We both have Windows.



On my end I typed:



ncat -l 3333


On his end I had him type:



ncat [my public IP] 3333


Nothing happened on my end, while his completed with "Ncat: ." and returned to the prompt.



I couldn't figure out what to do to fix this, so I decided, while he's busy, I'll test this out on two of my own laptops (one with Windows, the other with Linux, not sure if it should matter).



I found the same results ("Ncat: ." then back to prompt) only when I issued



ncat -l 3333


from Linux and



ncat [my public IP] 3333


from Windows.



The only scenario in which the chat/file-transfer did work was when I listened from Windows and did ncat [my public IP] 3333 from Linux.



Any ideas why this is happening, and what I can do to fix it?







networking file-transfer chat netcat






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 4 '13 at 19:35









jnovack

1,216619




1,216619










asked Mar 4 '13 at 23:33









EmilEmil

1134




1134




migrated from stackoverflow.com Mar 5 '13 at 7:36


This question came from our site for professional and enthusiast programmers.






migrated from stackoverflow.com Mar 5 '13 at 7:36


This question came from our site for professional and enthusiast programmers.















  • You did not tell wether it's working or not. At the moment, you don't like the blinking cursor. That's all you've told. Please give us more information of what works and what doesn't. And I suggest you portforwarding, if the connection could not be established.

    – Peter
    Mar 5 '13 at 7:50













  • @Peter: Read it again. He’s saying that the client process exits immediately upon being started.

    – Scott
    Mar 5 '13 at 20:53











  • Emil: Have you tried -v (and -vv and -vvv)? Do you have a sniffer (e.g., ethereal, Wireshark, tcpdump, …)? Can you see what is happening on the wire?

    – Scott
    Mar 5 '13 at 20:54











  • yes, I have Wireshark. I can try taking a look, but it is a little overwhelming, and I'm not sure what to look for. I took my first Routing/networking class last semester, so I'm new to this. I'll check though and see if anything looks...::ahem:: familiar

    – Emil
    Mar 6 '13 at 3:18





















  • You did not tell wether it's working or not. At the moment, you don't like the blinking cursor. That's all you've told. Please give us more information of what works and what doesn't. And I suggest you portforwarding, if the connection could not be established.

    – Peter
    Mar 5 '13 at 7:50













  • @Peter: Read it again. He’s saying that the client process exits immediately upon being started.

    – Scott
    Mar 5 '13 at 20:53











  • Emil: Have you tried -v (and -vv and -vvv)? Do you have a sniffer (e.g., ethereal, Wireshark, tcpdump, …)? Can you see what is happening on the wire?

    – Scott
    Mar 5 '13 at 20:54











  • yes, I have Wireshark. I can try taking a look, but it is a little overwhelming, and I'm not sure what to look for. I took my first Routing/networking class last semester, so I'm new to this. I'll check though and see if anything looks...::ahem:: familiar

    – Emil
    Mar 6 '13 at 3:18



















You did not tell wether it's working or not. At the moment, you don't like the blinking cursor. That's all you've told. Please give us more information of what works and what doesn't. And I suggest you portforwarding, if the connection could not be established.

– Peter
Mar 5 '13 at 7:50







You did not tell wether it's working or not. At the moment, you don't like the blinking cursor. That's all you've told. Please give us more information of what works and what doesn't. And I suggest you portforwarding, if the connection could not be established.

– Peter
Mar 5 '13 at 7:50















@Peter: Read it again. He’s saying that the client process exits immediately upon being started.

– Scott
Mar 5 '13 at 20:53





@Peter: Read it again. He’s saying that the client process exits immediately upon being started.

– Scott
Mar 5 '13 at 20:53













Emil: Have you tried -v (and -vv and -vvv)? Do you have a sniffer (e.g., ethereal, Wireshark, tcpdump, …)? Can you see what is happening on the wire?

– Scott
Mar 5 '13 at 20:54





Emil: Have you tried -v (and -vv and -vvv)? Do you have a sniffer (e.g., ethereal, Wireshark, tcpdump, …)? Can you see what is happening on the wire?

– Scott
Mar 5 '13 at 20:54













yes, I have Wireshark. I can try taking a look, but it is a little overwhelming, and I'm not sure what to look for. I took my first Routing/networking class last semester, so I'm new to this. I'll check though and see if anything looks...::ahem:: familiar

– Emil
Mar 6 '13 at 3:18







yes, I have Wireshark. I can try taking a look, but it is a little overwhelming, and I'm not sure what to look for. I took my first Routing/networking class last semester, so I'm new to this. I'll check though and see if anything looks...::ahem:: familiar

– Emil
Mar 6 '13 at 3:18












2 Answers
2






active

oldest

votes


















1














Check that there are no firewalls in the way (to check in Wireshark, verify that a TCP SYN packet arrives at the listening instance) and check that port forwarding is properly set up if you are accessing the internet through a firewall or home router. If you aren't getting a TCP SYN packet, work your way back to the originating machine until you see where it stops. If you see a TCP SYN packet incoming followed by an outgoing TCP SYN/ACK packet, make sure that packet is arriving at the originating node, and that it responds with a TCP ACK.



Based on the fact that it works when listening from Windows and ncatting in from Linux, I would check the personal firewall settings for the firewalls on both Linux and Windows and see if they are configured differently. Make sure you allow incoming traffic on the port you are listening on (in this case 3333).



One difference that exists with real Netcat between Linux and Windows is that in Windows there is a -L flag that causes persistent listening after a closure. This may not have anything to do with this issue, but I thought it was worth mentioning.






share|improve this answer































    2














    So, the last part of your post said it only worked locally when you listened from windows, and ran the client from Linux.



    Most likely your Linux firewall (most likely ufw - are you on Ubuntu or a variant?) Is set to allow outgoing and deny incoming unless it is established by your own outgoing connections. Somehow your Windows firewall is happy enough that you are listening with ncat that it just lets the incoming traffic through.



    In Linux run: sudo systemctl status ufw
    If ufw is up, then run: sudo ufw allow 3333
    Then try listening from Linux at Port 3333 and see if it works.
    Don't forget to deny port 3333 when you are finished with ncat - same syntax but use deny instead of allow.



    In the first case, wherein your friend couldn't connect to your machine, since your Windows machine can listen and initiate successfully over the local network, it is almost guaranteed that port 3333 on your machine is not forwarded to your router. When your friend tries ncatting to your IP, he is requesting a service from your router - not from your computer.



    If you login to your routers admin interface it should have an option for port forwarding/triggering. This might be in the advanced settings. Good luck and let us know if you have any more questions.



    PS. If you get this to work with your friend over the internet, I would suggest shutting it down after proof of concept. If you want to continue exposing your computer's port to the world wide web for ncat chatting then you should use ssl with ncat and you should monitor the port activity.






    share|improve this answer























      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%2f560969%2fncat-only-works-in-certain-scenarios%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      1














      Check that there are no firewalls in the way (to check in Wireshark, verify that a TCP SYN packet arrives at the listening instance) and check that port forwarding is properly set up if you are accessing the internet through a firewall or home router. If you aren't getting a TCP SYN packet, work your way back to the originating machine until you see where it stops. If you see a TCP SYN packet incoming followed by an outgoing TCP SYN/ACK packet, make sure that packet is arriving at the originating node, and that it responds with a TCP ACK.



      Based on the fact that it works when listening from Windows and ncatting in from Linux, I would check the personal firewall settings for the firewalls on both Linux and Windows and see if they are configured differently. Make sure you allow incoming traffic on the port you are listening on (in this case 3333).



      One difference that exists with real Netcat between Linux and Windows is that in Windows there is a -L flag that causes persistent listening after a closure. This may not have anything to do with this issue, but I thought it was worth mentioning.






      share|improve this answer




























        1














        Check that there are no firewalls in the way (to check in Wireshark, verify that a TCP SYN packet arrives at the listening instance) and check that port forwarding is properly set up if you are accessing the internet through a firewall or home router. If you aren't getting a TCP SYN packet, work your way back to the originating machine until you see where it stops. If you see a TCP SYN packet incoming followed by an outgoing TCP SYN/ACK packet, make sure that packet is arriving at the originating node, and that it responds with a TCP ACK.



        Based on the fact that it works when listening from Windows and ncatting in from Linux, I would check the personal firewall settings for the firewalls on both Linux and Windows and see if they are configured differently. Make sure you allow incoming traffic on the port you are listening on (in this case 3333).



        One difference that exists with real Netcat between Linux and Windows is that in Windows there is a -L flag that causes persistent listening after a closure. This may not have anything to do with this issue, but I thought it was worth mentioning.






        share|improve this answer


























          1












          1








          1







          Check that there are no firewalls in the way (to check in Wireshark, verify that a TCP SYN packet arrives at the listening instance) and check that port forwarding is properly set up if you are accessing the internet through a firewall or home router. If you aren't getting a TCP SYN packet, work your way back to the originating machine until you see where it stops. If you see a TCP SYN packet incoming followed by an outgoing TCP SYN/ACK packet, make sure that packet is arriving at the originating node, and that it responds with a TCP ACK.



          Based on the fact that it works when listening from Windows and ncatting in from Linux, I would check the personal firewall settings for the firewalls on both Linux and Windows and see if they are configured differently. Make sure you allow incoming traffic on the port you are listening on (in this case 3333).



          One difference that exists with real Netcat between Linux and Windows is that in Windows there is a -L flag that causes persistent listening after a closure. This may not have anything to do with this issue, but I thought it was worth mentioning.






          share|improve this answer













          Check that there are no firewalls in the way (to check in Wireshark, verify that a TCP SYN packet arrives at the listening instance) and check that port forwarding is properly set up if you are accessing the internet through a firewall or home router. If you aren't getting a TCP SYN packet, work your way back to the originating machine until you see where it stops. If you see a TCP SYN packet incoming followed by an outgoing TCP SYN/ACK packet, make sure that packet is arriving at the originating node, and that it responds with a TCP ACK.



          Based on the fact that it works when listening from Windows and ncatting in from Linux, I would check the personal firewall settings for the firewalls on both Linux and Windows and see if they are configured differently. Make sure you allow incoming traffic on the port you are listening on (in this case 3333).



          One difference that exists with real Netcat between Linux and Windows is that in Windows there is a -L flag that causes persistent listening after a closure. This may not have anything to do with this issue, but I thought it was worth mentioning.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 6 '13 at 19:26









          Freedom_BenFreedom_Ben

          24017




          24017

























              2














              So, the last part of your post said it only worked locally when you listened from windows, and ran the client from Linux.



              Most likely your Linux firewall (most likely ufw - are you on Ubuntu or a variant?) Is set to allow outgoing and deny incoming unless it is established by your own outgoing connections. Somehow your Windows firewall is happy enough that you are listening with ncat that it just lets the incoming traffic through.



              In Linux run: sudo systemctl status ufw
              If ufw is up, then run: sudo ufw allow 3333
              Then try listening from Linux at Port 3333 and see if it works.
              Don't forget to deny port 3333 when you are finished with ncat - same syntax but use deny instead of allow.



              In the first case, wherein your friend couldn't connect to your machine, since your Windows machine can listen and initiate successfully over the local network, it is almost guaranteed that port 3333 on your machine is not forwarded to your router. When your friend tries ncatting to your IP, he is requesting a service from your router - not from your computer.



              If you login to your routers admin interface it should have an option for port forwarding/triggering. This might be in the advanced settings. Good luck and let us know if you have any more questions.



              PS. If you get this to work with your friend over the internet, I would suggest shutting it down after proof of concept. If you want to continue exposing your computer's port to the world wide web for ncat chatting then you should use ssl with ncat and you should monitor the port activity.






              share|improve this answer




























                2














                So, the last part of your post said it only worked locally when you listened from windows, and ran the client from Linux.



                Most likely your Linux firewall (most likely ufw - are you on Ubuntu or a variant?) Is set to allow outgoing and deny incoming unless it is established by your own outgoing connections. Somehow your Windows firewall is happy enough that you are listening with ncat that it just lets the incoming traffic through.



                In Linux run: sudo systemctl status ufw
                If ufw is up, then run: sudo ufw allow 3333
                Then try listening from Linux at Port 3333 and see if it works.
                Don't forget to deny port 3333 when you are finished with ncat - same syntax but use deny instead of allow.



                In the first case, wherein your friend couldn't connect to your machine, since your Windows machine can listen and initiate successfully over the local network, it is almost guaranteed that port 3333 on your machine is not forwarded to your router. When your friend tries ncatting to your IP, he is requesting a service from your router - not from your computer.



                If you login to your routers admin interface it should have an option for port forwarding/triggering. This might be in the advanced settings. Good luck and let us know if you have any more questions.



                PS. If you get this to work with your friend over the internet, I would suggest shutting it down after proof of concept. If you want to continue exposing your computer's port to the world wide web for ncat chatting then you should use ssl with ncat and you should monitor the port activity.






                share|improve this answer


























                  2












                  2








                  2







                  So, the last part of your post said it only worked locally when you listened from windows, and ran the client from Linux.



                  Most likely your Linux firewall (most likely ufw - are you on Ubuntu or a variant?) Is set to allow outgoing and deny incoming unless it is established by your own outgoing connections. Somehow your Windows firewall is happy enough that you are listening with ncat that it just lets the incoming traffic through.



                  In Linux run: sudo systemctl status ufw
                  If ufw is up, then run: sudo ufw allow 3333
                  Then try listening from Linux at Port 3333 and see if it works.
                  Don't forget to deny port 3333 when you are finished with ncat - same syntax but use deny instead of allow.



                  In the first case, wherein your friend couldn't connect to your machine, since your Windows machine can listen and initiate successfully over the local network, it is almost guaranteed that port 3333 on your machine is not forwarded to your router. When your friend tries ncatting to your IP, he is requesting a service from your router - not from your computer.



                  If you login to your routers admin interface it should have an option for port forwarding/triggering. This might be in the advanced settings. Good luck and let us know if you have any more questions.



                  PS. If you get this to work with your friend over the internet, I would suggest shutting it down after proof of concept. If you want to continue exposing your computer's port to the world wide web for ncat chatting then you should use ssl with ncat and you should monitor the port activity.






                  share|improve this answer













                  So, the last part of your post said it only worked locally when you listened from windows, and ran the client from Linux.



                  Most likely your Linux firewall (most likely ufw - are you on Ubuntu or a variant?) Is set to allow outgoing and deny incoming unless it is established by your own outgoing connections. Somehow your Windows firewall is happy enough that you are listening with ncat that it just lets the incoming traffic through.



                  In Linux run: sudo systemctl status ufw
                  If ufw is up, then run: sudo ufw allow 3333
                  Then try listening from Linux at Port 3333 and see if it works.
                  Don't forget to deny port 3333 when you are finished with ncat - same syntax but use deny instead of allow.



                  In the first case, wherein your friend couldn't connect to your machine, since your Windows machine can listen and initiate successfully over the local network, it is almost guaranteed that port 3333 on your machine is not forwarded to your router. When your friend tries ncatting to your IP, he is requesting a service from your router - not from your computer.



                  If you login to your routers admin interface it should have an option for port forwarding/triggering. This might be in the advanced settings. Good luck and let us know if you have any more questions.



                  PS. If you get this to work with your friend over the internet, I would suggest shutting it down after proof of concept. If you want to continue exposing your computer's port to the world wide web for ncat chatting then you should use ssl with ncat and you should monitor the port activity.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 2 at 15:03









                  Guy GastineauGuy Gastineau

                  314




                  314






























                      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%2f560969%2fncat-only-works-in-certain-scenarios%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