How to reproduce the accept error in Linux












1















I'm learning Unix Network Programming Volume 1, I want to reproduce the accept error for RST in Linux.




  1. server: call socket(), bind(), listen(), and sleep(10)

  2. client: call socket(), connect(), setsockopt() of LINGER, close() and return

  3. server: call accept()


I think that the 3rd steps will get an error like ECONNABORTED, but not.



Do I want to know why?



I will appreciate it if you help me.



The follow is server code :



#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <stdio.h>
#include <strings.h>
#include <unistd.h>

int main(int argc, char* argv) {
int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
struct sockaddr_in addr;

bzero(&addr, sizeof addr);
addr.sin_family = AF_INET;
addr.sin_port = htons(6666);
inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

bind(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));
listen(sock, 5);
sleep(10);

if (accept(sock, NULL, NULL) < 0)
perror("error");
else
printf("right");

return 0;
}


The following is the client code



#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <stdio.h>
#include <strings.h>
#include <unistd.h>

int main(int argc, char* argv) {
int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
struct sockaddr_in addr;

bzero(&addr, sizeof addr);
addr.sin_family = AF_INET;
addr.sin_port = htons(6666);
inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

connect(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));

struct linger ling;
ling.l_onoff = 1;
ling.l_linger = 0;
setsockopt(sock, SOL_SOCKET, SO_LINGER, &ling, sizeof ling);
close(sock);

return 0;
}









share|improve this question





























    1















    I'm learning Unix Network Programming Volume 1, I want to reproduce the accept error for RST in Linux.




    1. server: call socket(), bind(), listen(), and sleep(10)

    2. client: call socket(), connect(), setsockopt() of LINGER, close() and return

    3. server: call accept()


    I think that the 3rd steps will get an error like ECONNABORTED, but not.



    Do I want to know why?



    I will appreciate it if you help me.



    The follow is server code :



    #include <arpa/inet.h>
    #include <netinet/in.h>
    #include <sys/socket.h>
    #include <stdio.h>
    #include <strings.h>
    #include <unistd.h>

    int main(int argc, char* argv) {
    int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    struct sockaddr_in addr;

    bzero(&addr, sizeof addr);
    addr.sin_family = AF_INET;
    addr.sin_port = htons(6666);
    inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

    bind(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));
    listen(sock, 5);
    sleep(10);

    if (accept(sock, NULL, NULL) < 0)
    perror("error");
    else
    printf("right");

    return 0;
    }


    The following is the client code



    #include <arpa/inet.h>
    #include <netinet/in.h>
    #include <sys/socket.h>
    #include <stdio.h>
    #include <strings.h>
    #include <unistd.h>

    int main(int argc, char* argv) {
    int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    struct sockaddr_in addr;

    bzero(&addr, sizeof addr);
    addr.sin_family = AF_INET;
    addr.sin_port = htons(6666);
    inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

    connect(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));

    struct linger ling;
    ling.l_onoff = 1;
    ling.l_linger = 0;
    setsockopt(sock, SOL_SOCKET, SO_LINGER, &ling, sizeof ling);
    close(sock);

    return 0;
    }









    share|improve this question



























      1












      1








      1








      I'm learning Unix Network Programming Volume 1, I want to reproduce the accept error for RST in Linux.




      1. server: call socket(), bind(), listen(), and sleep(10)

      2. client: call socket(), connect(), setsockopt() of LINGER, close() and return

      3. server: call accept()


      I think that the 3rd steps will get an error like ECONNABORTED, but not.



      Do I want to know why?



      I will appreciate it if you help me.



      The follow is server code :



      #include <arpa/inet.h>
      #include <netinet/in.h>
      #include <sys/socket.h>
      #include <stdio.h>
      #include <strings.h>
      #include <unistd.h>

      int main(int argc, char* argv) {
      int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
      struct sockaddr_in addr;

      bzero(&addr, sizeof addr);
      addr.sin_family = AF_INET;
      addr.sin_port = htons(6666);
      inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

      bind(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));
      listen(sock, 5);
      sleep(10);

      if (accept(sock, NULL, NULL) < 0)
      perror("error");
      else
      printf("right");

      return 0;
      }


      The following is the client code



      #include <arpa/inet.h>
      #include <netinet/in.h>
      #include <sys/socket.h>
      #include <stdio.h>
      #include <strings.h>
      #include <unistd.h>

      int main(int argc, char* argv) {
      int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
      struct sockaddr_in addr;

      bzero(&addr, sizeof addr);
      addr.sin_family = AF_INET;
      addr.sin_port = htons(6666);
      inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

      connect(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));

      struct linger ling;
      ling.l_onoff = 1;
      ling.l_linger = 0;
      setsockopt(sock, SOL_SOCKET, SO_LINGER, &ling, sizeof ling);
      close(sock);

      return 0;
      }









      share|improve this question
















      I'm learning Unix Network Programming Volume 1, I want to reproduce the accept error for RST in Linux.




      1. server: call socket(), bind(), listen(), and sleep(10)

      2. client: call socket(), connect(), setsockopt() of LINGER, close() and return

      3. server: call accept()


      I think that the 3rd steps will get an error like ECONNABORTED, but not.



      Do I want to know why?



      I will appreciate it if you help me.



      The follow is server code :



      #include <arpa/inet.h>
      #include <netinet/in.h>
      #include <sys/socket.h>
      #include <stdio.h>
      #include <strings.h>
      #include <unistd.h>

      int main(int argc, char* argv) {
      int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
      struct sockaddr_in addr;

      bzero(&addr, sizeof addr);
      addr.sin_family = AF_INET;
      addr.sin_port = htons(6666);
      inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

      bind(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));
      listen(sock, 5);
      sleep(10);

      if (accept(sock, NULL, NULL) < 0)
      perror("error");
      else
      printf("right");

      return 0;
      }


      The following is the client code



      #include <arpa/inet.h>
      #include <netinet/in.h>
      #include <sys/socket.h>
      #include <stdio.h>
      #include <strings.h>
      #include <unistd.h>

      int main(int argc, char* argv) {
      int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
      struct sockaddr_in addr;

      bzero(&addr, sizeof addr);
      addr.sin_family = AF_INET;
      addr.sin_port = htons(6666);
      inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

      connect(sock, (struct sockaddr*)(&addr), (socklen_t)(sizeof addr));

      struct linger ling;
      ling.l_onoff = 1;
      ling.l_linger = 0;
      setsockopt(sock, SOL_SOCKET, SO_LINGER, &ling, sizeof ling);
      close(sock);

      return 0;
      }






      c linux operating-system unix-socket






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 20 '18 at 17:22







      Yunbin Liu

















      asked Nov 13 '18 at 8:13









      Yunbin LiuYunbin Liu

      1,160313




      1,160313
























          2 Answers
          2






          active

          oldest

          votes


















          2














          Nope. I think you'll get an empty, but complete connection (with no data). The kernel will manage the complete connection establishment and then it'll get an immediate FIN packet (meaning EOF, not reset) and will handle it (or wait for user space process to close its side, to send the FIN to the other side) For a connection abort you need to reboot the client machine (or the server) without allowing it to send the FIN packets (or disconnecting it from the network before rebooting it) An ACK is never answered, so you won't get a RST sent from an ACK.



          RST packets are sent automatically by the kernel when some state mismatch is in between two parties. For this to happen in a correct implementation you must force such a state mismatch (this is why the machine reboot is necessary)




          • Make a connection between both parties and stop it (with a sleep) to ensure the connection is in the ESTABLISHED state before disconnecting the cable.

          • disconnect physically one of the peers from the network, so you don't allow its traffic to go to the network.

          • reboot the machine, so all sockets are in the IDLE state.

          • reconnect the cable. As soon as the waiting machine gets out of the sleep and begins sending packets again, it will receive a RST segment from the other side, because it has been rebooted and TCP does not know about that connection.


          Other ways of getting a RST segment involve bad implementations of TCP, or mangling the packets in transit (changing the sender or receiver sequence numbers in transit)



          The purpose of RST packets is not to add functionality to TCP, but to detect misbehaviours, to there should be no means to get a reset with proper use of sockets. Listen syscall is there to allow you to reserve resources in kernel space to allow the user space process to prepare to handle the connection while the clients are trying to connect. If you do what you intend you'll get a connection with no data, but valid connection, SO_LINGER is there to force a loss of status when machines don't have the time to send the packets to each other... but being connected, the whole connection is handled in the kernel and no abort is to be expected.






          share|improve this answer
























          • I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

            – Yunbin Liu
            Nov 20 '18 at 17:52













          • For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

            – Luis Colorado
            Nov 21 '18 at 5:54



















          0















          Linux accept() (and accept4()) passes already-pending network errors
          on the new socket as an error code from accept(). This behavior
          differs from other BSD socket implementations. For reliable
          operation the application should detect the network errors defined
          for the protocol after accept() and treat them like EAGAIN by
          retrying. In the case of TCP/IP, these are ENETDOWN, EPROTO,
          ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and
          ENETUNREACH.




          http://man7.org/linux/man-pages/man2/accept.2.html






          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            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%2fstackoverflow.com%2fquestions%2f53276541%2fhow-to-reproduce-the-accept-error-in-linux%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









            2














            Nope. I think you'll get an empty, but complete connection (with no data). The kernel will manage the complete connection establishment and then it'll get an immediate FIN packet (meaning EOF, not reset) and will handle it (or wait for user space process to close its side, to send the FIN to the other side) For a connection abort you need to reboot the client machine (or the server) without allowing it to send the FIN packets (or disconnecting it from the network before rebooting it) An ACK is never answered, so you won't get a RST sent from an ACK.



            RST packets are sent automatically by the kernel when some state mismatch is in between two parties. For this to happen in a correct implementation you must force such a state mismatch (this is why the machine reboot is necessary)




            • Make a connection between both parties and stop it (with a sleep) to ensure the connection is in the ESTABLISHED state before disconnecting the cable.

            • disconnect physically one of the peers from the network, so you don't allow its traffic to go to the network.

            • reboot the machine, so all sockets are in the IDLE state.

            • reconnect the cable. As soon as the waiting machine gets out of the sleep and begins sending packets again, it will receive a RST segment from the other side, because it has been rebooted and TCP does not know about that connection.


            Other ways of getting a RST segment involve bad implementations of TCP, or mangling the packets in transit (changing the sender or receiver sequence numbers in transit)



            The purpose of RST packets is not to add functionality to TCP, but to detect misbehaviours, to there should be no means to get a reset with proper use of sockets. Listen syscall is there to allow you to reserve resources in kernel space to allow the user space process to prepare to handle the connection while the clients are trying to connect. If you do what you intend you'll get a connection with no data, but valid connection, SO_LINGER is there to force a loss of status when machines don't have the time to send the packets to each other... but being connected, the whole connection is handled in the kernel and no abort is to be expected.






            share|improve this answer
























            • I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

              – Yunbin Liu
              Nov 20 '18 at 17:52













            • For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

              – Luis Colorado
              Nov 21 '18 at 5:54
















            2














            Nope. I think you'll get an empty, but complete connection (with no data). The kernel will manage the complete connection establishment and then it'll get an immediate FIN packet (meaning EOF, not reset) and will handle it (or wait for user space process to close its side, to send the FIN to the other side) For a connection abort you need to reboot the client machine (or the server) without allowing it to send the FIN packets (or disconnecting it from the network before rebooting it) An ACK is never answered, so you won't get a RST sent from an ACK.



            RST packets are sent automatically by the kernel when some state mismatch is in between two parties. For this to happen in a correct implementation you must force such a state mismatch (this is why the machine reboot is necessary)




            • Make a connection between both parties and stop it (with a sleep) to ensure the connection is in the ESTABLISHED state before disconnecting the cable.

            • disconnect physically one of the peers from the network, so you don't allow its traffic to go to the network.

            • reboot the machine, so all sockets are in the IDLE state.

            • reconnect the cable. As soon as the waiting machine gets out of the sleep and begins sending packets again, it will receive a RST segment from the other side, because it has been rebooted and TCP does not know about that connection.


            Other ways of getting a RST segment involve bad implementations of TCP, or mangling the packets in transit (changing the sender or receiver sequence numbers in transit)



            The purpose of RST packets is not to add functionality to TCP, but to detect misbehaviours, to there should be no means to get a reset with proper use of sockets. Listen syscall is there to allow you to reserve resources in kernel space to allow the user space process to prepare to handle the connection while the clients are trying to connect. If you do what you intend you'll get a connection with no data, but valid connection, SO_LINGER is there to force a loss of status when machines don't have the time to send the packets to each other... but being connected, the whole connection is handled in the kernel and no abort is to be expected.






            share|improve this answer
























            • I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

              – Yunbin Liu
              Nov 20 '18 at 17:52













            • For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

              – Luis Colorado
              Nov 21 '18 at 5:54














            2












            2








            2







            Nope. I think you'll get an empty, but complete connection (with no data). The kernel will manage the complete connection establishment and then it'll get an immediate FIN packet (meaning EOF, not reset) and will handle it (or wait for user space process to close its side, to send the FIN to the other side) For a connection abort you need to reboot the client machine (or the server) without allowing it to send the FIN packets (or disconnecting it from the network before rebooting it) An ACK is never answered, so you won't get a RST sent from an ACK.



            RST packets are sent automatically by the kernel when some state mismatch is in between two parties. For this to happen in a correct implementation you must force such a state mismatch (this is why the machine reboot is necessary)




            • Make a connection between both parties and stop it (with a sleep) to ensure the connection is in the ESTABLISHED state before disconnecting the cable.

            • disconnect physically one of the peers from the network, so you don't allow its traffic to go to the network.

            • reboot the machine, so all sockets are in the IDLE state.

            • reconnect the cable. As soon as the waiting machine gets out of the sleep and begins sending packets again, it will receive a RST segment from the other side, because it has been rebooted and TCP does not know about that connection.


            Other ways of getting a RST segment involve bad implementations of TCP, or mangling the packets in transit (changing the sender or receiver sequence numbers in transit)



            The purpose of RST packets is not to add functionality to TCP, but to detect misbehaviours, to there should be no means to get a reset with proper use of sockets. Listen syscall is there to allow you to reserve resources in kernel space to allow the user space process to prepare to handle the connection while the clients are trying to connect. If you do what you intend you'll get a connection with no data, but valid connection, SO_LINGER is there to force a loss of status when machines don't have the time to send the packets to each other... but being connected, the whole connection is handled in the kernel and no abort is to be expected.






            share|improve this answer













            Nope. I think you'll get an empty, but complete connection (with no data). The kernel will manage the complete connection establishment and then it'll get an immediate FIN packet (meaning EOF, not reset) and will handle it (or wait for user space process to close its side, to send the FIN to the other side) For a connection abort you need to reboot the client machine (or the server) without allowing it to send the FIN packets (or disconnecting it from the network before rebooting it) An ACK is never answered, so you won't get a RST sent from an ACK.



            RST packets are sent automatically by the kernel when some state mismatch is in between two parties. For this to happen in a correct implementation you must force such a state mismatch (this is why the machine reboot is necessary)




            • Make a connection between both parties and stop it (with a sleep) to ensure the connection is in the ESTABLISHED state before disconnecting the cable.

            • disconnect physically one of the peers from the network, so you don't allow its traffic to go to the network.

            • reboot the machine, so all sockets are in the IDLE state.

            • reconnect the cable. As soon as the waiting machine gets out of the sleep and begins sending packets again, it will receive a RST segment from the other side, because it has been rebooted and TCP does not know about that connection.


            Other ways of getting a RST segment involve bad implementations of TCP, or mangling the packets in transit (changing the sender or receiver sequence numbers in transit)



            The purpose of RST packets is not to add functionality to TCP, but to detect misbehaviours, to there should be no means to get a reset with proper use of sockets. Listen syscall is there to allow you to reserve resources in kernel space to allow the user space process to prepare to handle the connection while the clients are trying to connect. If you do what you intend you'll get a connection with no data, but valid connection, SO_LINGER is there to force a loss of status when machines don't have the time to send the packets to each other... but being connected, the whole connection is handled in the kernel and no abort is to be expected.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 20 '18 at 8:16









            Luis ColoradoLuis Colorado

            4,0941718




            4,0941718













            • I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

              – Yunbin Liu
              Nov 20 '18 at 17:52













            • For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

              – Luis Colorado
              Nov 21 '18 at 5:54



















            • I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

              – Yunbin Liu
              Nov 20 '18 at 17:52













            • For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

              – Luis Colorado
              Nov 21 '18 at 5:54

















            I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

            – Yunbin Liu
            Nov 20 '18 at 17:52







            I fix a mistake of ling.l_linger = 0;. After I set setsocketopt of struct linger {1, 0}, close() should send RST to server, but I don't get it. see this

            – Yunbin Liu
            Nov 20 '18 at 17:52















            For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

            – Luis Colorado
            Nov 21 '18 at 5:54





            For that to happen you must avoid the kernels (on both machines) to communicate. So you get different connection status on each. SO_LINGER is only used to avoid the TIMEOUT state, which only is passed by the process that does the active close, and this state is maintained to discard possible repeated ACK's, so I think you are not going to get a RST anyway.

            – Luis Colorado
            Nov 21 '18 at 5:54













            0















            Linux accept() (and accept4()) passes already-pending network errors
            on the new socket as an error code from accept(). This behavior
            differs from other BSD socket implementations. For reliable
            operation the application should detect the network errors defined
            for the protocol after accept() and treat them like EAGAIN by
            retrying. In the case of TCP/IP, these are ENETDOWN, EPROTO,
            ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and
            ENETUNREACH.




            http://man7.org/linux/man-pages/man2/accept.2.html






            share|improve this answer




























              0















              Linux accept() (and accept4()) passes already-pending network errors
              on the new socket as an error code from accept(). This behavior
              differs from other BSD socket implementations. For reliable
              operation the application should detect the network errors defined
              for the protocol after accept() and treat them like EAGAIN by
              retrying. In the case of TCP/IP, these are ENETDOWN, EPROTO,
              ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and
              ENETUNREACH.




              http://man7.org/linux/man-pages/man2/accept.2.html






              share|improve this answer


























                0












                0








                0








                Linux accept() (and accept4()) passes already-pending network errors
                on the new socket as an error code from accept(). This behavior
                differs from other BSD socket implementations. For reliable
                operation the application should detect the network errors defined
                for the protocol after accept() and treat them like EAGAIN by
                retrying. In the case of TCP/IP, these are ENETDOWN, EPROTO,
                ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and
                ENETUNREACH.




                http://man7.org/linux/man-pages/man2/accept.2.html






                share|improve this answer














                Linux accept() (and accept4()) passes already-pending network errors
                on the new socket as an error code from accept(). This behavior
                differs from other BSD socket implementations. For reliable
                operation the application should detect the network errors defined
                for the protocol after accept() and treat them like EAGAIN by
                retrying. In the case of TCP/IP, these are ENETDOWN, EPROTO,
                ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and
                ENETUNREACH.




                http://man7.org/linux/man-pages/man2/accept.2.html







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 22 '18 at 15:13









                Yunbin LiuYunbin Liu

                1,160313




                1,160313






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • 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%2fstackoverflow.com%2fquestions%2f53276541%2fhow-to-reproduce-the-accept-error-in-linux%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







                    這個網誌中的熱門文章

                    Hercules Kyvelos

                    Tangent Lines Diagram Along Smooth Curve

                    Yusuf al-Mu'taman ibn Hud