TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used - TCP-IP

This is a discussion on TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used - TCP-IP ; When a SYN packet was sent from the client machine to the port 25 of a remote machine via the libnet_write. A RST packet (the 3rd packet listed below) was sent right away from the client before or after the ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

  1. TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    When a SYN packet was sent from the client machine to the port 25 of a
    remote machine via the libnet_write. A RST packet (the 3rd packet
    listed below) was sent right away from the client before or after the
    SYN|ACK packet was sent back from the server machine. That RST seemed
    to be sent by the TCP stack because the TCP client didn't send it. Can
    you explain and resolve this unknown RST problem during establishing
    the TCP connection? My goal is to avoid the RST packet being sent so
    that the TCP connection can be established and other SMTP commands can
    be sent from the client thereafter. Any Idea? Thanks in advance.

    Packets captured and libnet codes sending the SYN and ACK packets are
    listed below:

    Packet number 1:
    From: 10.103.3.80 To: 10.103.3.79
    seq: 1500
    ack: 0
    th_flags: 2
    Protocol: TCP
    Src port: 27
    Dst port: 25
    Payload (0 bytes):
    Hex values:

    Packet number 2:
    From: 10.103.3.79 To: 10.103.3.80
    seq: 1540646009
    ack: 1501
    th_flags: 12
    Protocol: TCP
    Src port: 25
    Dst port: 27
    Payload (0 bytes):
    Hex values:

    Packet number 3:
    From: 10.103.3.80 To: 10.103.3.79
    seq: 1501
    ack: 0
    th_flags: 4
    Protocol: TCP
    Src port: 27
    Dst port: 25
    Payload (0 bytes):
    Hex values:

    Packet number 4:
    From: 10.103.3.80 To: 10.103.3.79
    seq: 1501
    ack: 1540646010
    th_flags: 10
    Protocol: TCP
    Src port: 27
    Dst port: 25
    Payload (40 bytes): E..(....@.^r.g.P.g.O............P....]..
    Hex values: 45 00 00 28 00 f2 00 00 40 06 5e 72 0a 67 03 50 0a 67 03
    4f 00 1b 00 19 00 00 05 dc 00 00 00 00 50 02 7f ff 0e 5d 00 0a

    Packet number 5:
    From: 10.103.3.80 To: 10.103.3.79
    seq: 1501
    ack: 1540646010
    th_flags: 10
    Protocol: TCP
    Src port: 27
    Dst port: 25
    Payload (97 bytes): EHLO 10.103.3.80 .E..(....@.^r.g.P.g.O........
    [.dzP...M...E..(....@.^r.g.P.g.O............P ....]..
    Hex values: 45 48 4c 4f 20 31 30 2e 33 2e 31 30 33 2e 38 30 00 45 00

    l = libnet_init(
    LIBNET_RAW4,
    NULL,
    errbuf);
    t = libnet_build_tcp(
    src_prt, /* 27 */
    dst_prt, /* 25 */
    send_seq, /* 1500 */
    send_ack, /* 0 */
    TH_SYN, /* control flags */
    32767, /* window size */
    0, /* checksum */
    10, /* urgent pointer */
    LIBNET_TCP_H + payload_s, /* payload_s is 0 */
    payload, /* NULL */
    payload_s, /* payload size */
    l, /* libnet handle */
    0); /* libnet id */

    t = libnet_build_ipv4(
    LIBNET_IPV4_H + LIBNET_TCP_H + payload_s, /* length */
    0, /* TOS */
    242, /* IP ID */
    0, /* IP Frag */
    64, /* TTL */
    IPPROTO_TCP, /* protocol */
    0, /* checksum */
    src_ip, /* 10.103.3.80 */
    dst_ip, /* 10.103.3.79 */
    NULL, /* payload */
    0, /* payload size */
    l, /* libnet handle */
    0); /* libnet id */


    c = libnet_write(l); // send the initial SYN packet out

    // then client captured the SYN&ACK packet from the server at the port
    25
    // then do the libnet_build_tcp, libnet_build_ipv4 and libnet_write
    after getting the expected SYN&ACK packet => shown as the packet 5
    listed above. My code doesn't send the packet 3 (RST - as listed
    above) from the client site (port 27), but it was sent (by?). So the
    TCP connection can't be established.


  2. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 24, 10:15 am, slsworking wrote:
    > When a SYN packet was sent from the client machine to the port 25 of a
    > remote machine via the libnet_write. A RST packet (the 3rd packet
    > listed below) was sent right away from the client before or after the
    > SYN|ACK packet was sent back from the server machine. That RST seemed
    > to be sent by the TCP stack because the TCP client didn't send it. Can
    > you explain and resolve this unknown RST problem during establishing
    > the TCP connection? My goal is to avoid the RST packet being sent so
    > that the TCP connection can be established and other SMTP commands can
    > be sent from the client thereafter. Any Idea? Thanks in advance.
    >
    > Packets captured and libnet codes sending the SYN and ACK packets are
    > listed below:
    >
    > Packet number 1:
    > From: 10.103.3.80 To: 10.103.3.79
    > seq: 1500
    > ack: 0
    > th_flags: 2
    > Protocol: TCP
    > Src port: 27
    > Dst port: 25
    > Payload (0 bytes):
    > Hex values:
    >
    > Packet number 2:
    > From: 10.103.3.79 To: 10.103.3.80
    > seq: 1540646009
    > ack: 1501
    > th_flags: 12
    > Protocol: TCP
    > Src port: 25
    > Dst port: 27
    > Payload (0 bytes):
    > Hex values:
    >
    > Packet number 3:
    > From: 10.103.3.80 To: 10.103.3.79
    > seq: 1501
    > ack: 0
    > th_flags: 4
    > Protocol: TCP
    > Src port: 27
    > Dst port: 25
    > Payload (0 bytes):
    > Hex values:
    >
    > Packet number 4:
    > From: 10.103.3.80 To: 10.103.3.79
    > seq: 1501
    > ack: 1540646010
    > th_flags: 10
    > Protocol: TCP
    > Src port: 27
    > Dst port: 25
    > Payload (40 bytes): E..(....@.^r.g.P.g.O............P....]..
    > Hex values: 45 00 00 28 00 f2 00 00 40 06 5e 72 0a 67 03 50 0a 67 03
    > 4f 00 1b 00 19 00 00 05 dc 00 00 00 00 50 02 7f ff 0e 5d 00 0a

    [snip]

    OK, let me see if I can summarize the sequence of events

    1: Using an API that bypasses the normal TCP/IP facilities and builds
    it's own TCP records on top of RAW sockets, you send out the first
    part of the three way handshake (the SYN).

    2: To this, the other end responds with the 2nd part of the handshake
    (a SYN,ACK)

    3: Again, using the bypass API, you build your own ACK to complete the
    handshake, but before you can send it, something on your side sends an
    RST.

    Let's ignore the server for a moment, and just concentrate on what
    your client-side TCP/IP stack sees. Since you use raw sockets, your
    client side TCP/IP stack is unaware that you have appropriated TCP
    port 27 for use in a conversation. Your TCP/IP stack sees a TCP SYN/
    ACK packet for a port that (to it's knowledge) does not have any
    outstanding connections. So, it sends a RST, refusing the SYN/ACK
    packet.

    This happens because you used libnet to bypass the connection
    management facilities (along with everything else) of your TCP/IP
    stack. Either libnet is unable to properly allocate the TCP port on
    your client side, or you have not set the proper options to cause it
    to allocate the port. Either way, your TCP stack is properly handling
    an unsolicited packet by returning a RST. You have to find a way
    within your libnet api to tell the client stack that such connections
    are allowed.

    Why are you using libnet instead of the standard sockets calls? You
    wouldn't have this problem (or the overhead of coding the low-level
    TCP handshake into your application) if you used the appropriate
    system calls instead of this api to "construct and inject network
    packets".

    HTH
    --
    Lew


  3. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    And if you must use your own stack you should make certain that the IP
    and ARP saps are not bound to the interface(s) in question by the host
    stack.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 24, 10:15 am, slsworking wrote:
    > When a SYN packet was sent from the client machine to the port 25 of a
    > remote machine via the libnet_write.

    [snip]

    It just occurred to me that the obvious reason to use libnet and raw
    sockets rather than the builtin TCP/IP stack and system API (sockets)
    to talk to an SMTP server is if you didn't want your conversation with
    the SMTP server to be observable using the standard network tools
    (such as netstat) on the client machine. The end conclusion of the
    logic chain thus started is that you are writing some sort of
    application that surreptitiously emails data from client machines to a
    central server, much like a trojan or virus.



  5. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 24, 11:51 am, Lew Pitcher wrote:
    > On Sep 24, 10:15 am, slsworking wrote:
    >
    >
    >
    > > When a SYN packet was sent from the client machine to the port 25 of a
    > > remote machine via the libnet_write. A RST packet (the 3rd packet
    > > listed below) was sent right away from the client before or after the
    > > SYN|ACK packet was sent back from the server machine. That RST seemed
    > > to be sent by the TCP stack because the TCP client didn't send it. Can
    > > you explain and resolve this unknown RST problem during establishing
    > > the TCP connection? My goal is to avoid the RST packet being sent so
    > > that the TCP connection can be established and other SMTP commands can
    > > be sent from the client thereafter. Any Idea? Thanks in advance.

    >
    > > Packets captured and libnet codes sending the SYN and ACK packets are
    > > listed below:

    >
    > > Packet number 1:
    > > From: 10.103.3.80 To: 10.103.3.79
    > > seq: 1500
    > > ack: 0
    > > th_flags: 2
    > > Protocol: TCP
    > > Src port: 27
    > > Dst port: 25
    > > Payload (0 bytes):
    > > Hex values:

    >
    > > Packet number 2:
    > > From: 10.103.3.79 To: 10.103.3.80
    > > seq: 1540646009
    > > ack: 1501
    > > th_flags: 12
    > > Protocol: TCP
    > > Src port: 25
    > > Dst port: 27
    > > Payload (0 bytes):
    > > Hex values:

    >
    > > Packet number 3:
    > > From: 10.103.3.80 To: 10.103.3.79
    > > seq: 1501
    > > ack: 0
    > > th_flags: 4
    > > Protocol: TCP
    > > Src port: 27
    > > Dst port: 25
    > > Payload (0 bytes):
    > > Hex values:

    >
    > > Packet number 4:
    > > From: 10.103.3.80 To: 10.103.3.79
    > > seq: 1501
    > > ack: 1540646010
    > > th_flags: 10
    > > Protocol: TCP
    > > Src port: 27
    > > Dst port: 25
    > > Payload (40 bytes): E..(....@.^r.g.P.g.O............P....]..
    > > Hex values: 45 00 00 28 00 f2 00 00 40 06 5e 72 0a 67 03 50 0a 67 03
    > > 4f 00 1b 00 19 00 00 05 dc 00 00 00 00 50 02 7f ff 0e 5d 00 0a

    >
    > [snip]
    >
    > OK, let me see if I can summarize the sequence of events
    >
    > 1: Using an API that bypasses the normal TCP/IP facilities and builds
    > it's own TCP records on top of RAW sockets, you send out the first
    > part of the three way handshake (the SYN).
    >
    > 2: To this, the other end responds with the 2nd part of the handshake
    > (a SYN,ACK)
    >
    > 3: Again, using the bypass API, you build your own ACK to complete the
    > handshake, but before you can send it, something on your side sends an
    > RST.
    >
    > Let's ignore the server for a moment, and just concentrate on what
    > your client-side TCP/IP stack sees. Since you use raw sockets, your
    > client side TCP/IP stack is unaware that you have appropriated TCP
    > port 27 for use in a conversation. Your TCP/IP stack sees a TCP SYN/
    > ACK packet for a port that (to it's knowledge) does not have any
    > outstanding connections. So, it sends a RST, refusing the SYN/ACK
    > packet.
    >
    > This happens because you used libnet to bypass the connection
    > management facilities (along with everything else) of your TCP/IP
    > stack. Either libnet is unable to properly allocate the TCP port on
    > your client side, or you have not set the proper options to cause it
    > to allocate the port. Either way, your TCP stack is properly handling
    > an unsolicited packet by returning a RST. You have to find a way
    > within your libnet api to tell the client stack that such connections
    > are allowed.
    >
    > Why are you using libnet instead of the standard sockets calls? You
    > wouldn't have this problem (or the overhead of coding the low-level
    > TCP handshake into your application) if you used the appropriate
    > system calls instead of this api to "construct and inject network
    > packets".
    >
    > HTH
    > --
    > Lew- Hide quoted text -
    >
    > - Show quoted text -


    Lew:

    >> Why are you using libnet instead of the standard sockets calls? You
    >> wouldn't have this problem (or the overhead of coding the low-level
    >> TCP handshake into your application) if you used the appropriate
    >> system calls instead of this api to "construct and inject network
    >> packets".


    Do you know where to get sample calls of the standard sockets calls?
    My purpose is to establish the TCP connection with the sendmail at the
    port 25 and send series of SMTP commands thereafter. Thanks again.

    sls


  6. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 24, 1:21 pm, Lew Pitcher wrote:
    > On Sep 24, 10:15 am, slsworking wrote:> When a SYN packet was sent from the client machine to the port 25 of a
    > > remote machine via the libnet_write.

    >
    > [snip]
    >
    > It just occurred to me that the obvious reason to use libnet and raw
    > sockets rather than the builtin TCP/IP stack and system API (sockets)
    > to talk to an SMTP server is if you didn't want your conversation with
    > the SMTP server to be observable using the standard network tools
    > (such as netstat) on the client machine. The end conclusion of the
    > logic chain thus started is that you are writing some sort of
    > application that surreptitiously emails data from client machines to a
    > central server, much like a trojan or virus.


    My application is to send various SMTP commands to the sendmail and
    those packet will be passed to our SMTP packet mornitoring application
    at the same time for the testing purpose. Is there a way for the TCP/
    IP stack not to see any TCP/IP packets sent by libnet and also not to
    see packets sent back from the sendmail/server? If yes, then
    unexpected RST won't be sent back by the stack. Please let me know if
    you have some code example as asked in my previous response. Thanks.

    sls


  7. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 25, 11:04 am, slsworking wrote:
    > On Sep 24, 11:51 am, Lew Pitcher wrote:
    >
    >
    >
    > > On Sep 24, 10:15 am, slsworking wrote:

    >
    > > > When a SYN packet was sent from the client machine to the port 25 of a
    > > > remote machine via the libnet_write. A RST packet (the 3rd packet
    > > > listed below) was sent right away from the client before or after the
    > > > SYN|ACK packet was sent back from the server machine. That RST seemed
    > > > to be sent by the TCP stack because the TCP client didn't send it. Can
    > > > you explain and resolve this unknown RST problem during establishing
    > > > the TCP connection? My goal is to avoid the RST packet being sent so
    > > > that the TCP connection can be established and other SMTP commands can
    > > > be sent from the client thereafter. Any Idea? Thanks in advance.

    >
    > > > Packets captured and libnet codes sending the SYN and ACK packets are
    > > > listed below:

    >
    > > > Packet number 1:
    > > > From: 10.103.3.80 To: 10.103.3.79
    > > > seq: 1500
    > > > ack: 0
    > > > th_flags: 2
    > > > Protocol: TCP
    > > > Src port: 27
    > > > Dst port: 25
    > > > Payload (0 bytes):
    > > > Hex values:

    >
    > > > Packet number 2:
    > > > From: 10.103.3.79 To: 10.103.3.80
    > > > seq: 1540646009
    > > > ack: 1501
    > > > th_flags: 12
    > > > Protocol: TCP
    > > > Src port: 25
    > > > Dst port: 27
    > > > Payload (0 bytes):
    > > > Hex values:

    >
    > > > Packet number 3:
    > > > From: 10.103.3.80 To: 10.103.3.79
    > > > seq: 1501
    > > > ack: 0
    > > > th_flags: 4
    > > > Protocol: TCP
    > > > Src port: 27
    > > > Dst port: 25
    > > > Payload (0 bytes):
    > > > Hex values:

    >
    > > > Packet number 4:
    > > > From: 10.103.3.80 To: 10.103.3.79
    > > > seq: 1501
    > > > ack: 1540646010
    > > > th_flags: 10
    > > > Protocol: TCP
    > > > Src port: 27
    > > > Dst port: 25
    > > > Payload (40 bytes): E..(....@.^r.g.P.g.O............P....]..
    > > > Hex values: 45 00 00 28 00 f2 00 00 40 06 5e 72 0a 67 03 50 0a 67 03
    > > > 4f 00 1b 00 19 00 00 05 dc 00 00 00 00 50 02 7f ff 0e 5d 00 0a

    >
    > > [snip]

    >
    > > OK, let me see if I can summarize the sequence of events

    >
    > > 1: Using an API that bypasses the normal TCP/IP facilities and builds
    > > it's own TCP records on top of RAW sockets, you send out the first
    > > part of the three way handshake (the SYN).

    >
    > > 2: To this, the other end responds with the 2nd part of the handshake
    > > (a SYN,ACK)

    >
    > > 3: Again, using the bypass API, you build your own ACK to complete the
    > > handshake, but before you can send it, something on your side sends an
    > > RST.

    >
    > > Let's ignore the server for a moment, and just concentrate on what
    > > your client-side TCP/IP stack sees. Since you use raw sockets, your
    > > client side TCP/IP stack is unaware that you have appropriated TCP
    > > port 27 for use in a conversation. Your TCP/IP stack sees a TCP SYN/
    > > ACK packet for a port that (to it's knowledge) does not have any
    > > outstanding connections. So, it sends a RST, refusing the SYN/ACK
    > > packet.

    >
    > > This happens because you used libnet to bypass the connection
    > > management facilities (along with everything else) of your TCP/IP
    > > stack. Either libnet is unable to properly allocate the TCP port on
    > > your client side, or you have not set the proper options to cause it
    > > to allocate the port. Either way, your TCP stack is properly handling
    > > an unsolicited packet by returning a RST. You have to find a way
    > > within your libnet api to tell the client stack that such connections
    > > are allowed.

    >
    > > Why are you using libnet instead of the standard sockets calls? You
    > > wouldn't have this problem (or the overhead of coding the low-level
    > > TCP handshake into your application) if you used the appropriate
    > > system calls instead of this api to "construct and inject network
    > > packets".

    >
    > > HTH
    > > --
    > > Lew- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Lew:
    >
    > >> Why are you using libnet instead of the standard sockets calls? You
    > >> wouldn't have this problem (or the overhead of coding the low-level
    > >> TCP handshake into your application) if you used the appropriate
    > >> system calls instead of this api to "construct and inject network
    > >> packets".

    >
    > Do you know where to get sample calls of the standard sockets calls?
    > My purpose is to establish the TCP connection with the sendmail at the
    > port 25 and send series of SMTP commands thereafter. Thanks again.


    Take a look at http://www.frostbytes.com/~jimf/pape...s/sockets.html
    which is an html-ified version of a standard "introduction to sockets"
    paper written 20 years ago. This should get you started in sockets
    programming.




  8. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 25, 11:12 am, slsworking wrote:
    > On Sep 24, 1:21 pm, Lew Pitcher wrote:
    >
    > > On Sep 24, 10:15 am, slsworking wrote:> When a SYN packet was sent from the client machine to the port 25 of a
    > > > remote machine via the libnet_write.

    >
    > > [snip]

    >
    > > It just occurred to me that the obvious reason to use libnet and raw
    > > sockets rather than the builtin TCP/IP stack and system API (sockets)
    > > to talk to an SMTP server is if you didn't want your conversation with
    > > the SMTP server to be observable using the standard network tools
    > > (such as netstat) on the client machine. The end conclusion of the
    > > logic chain thus started is that you are writing some sort of
    > > application that surreptitiously emails data from client machines to a
    > > central server, much like a trojan or virus.

    >
    > My application is to send various SMTP commands to the sendmail and
    > those packet will be passed to our SMTP packet mornitoring application
    > at the same time for the testing purpose.
    > Is there a way for the TCP/IP stack not to see any TCP/IP packets sent by libnet


    That's the situation right now. Your TCP/IP stack doesn't see the
    outbound libnet packets at all

    > and also not to see packets sent back from the sendmail/server?


    Sorry, but no. That's the job of the TCP/IP stack, to manage TCP/IP
    data coming to and leaving from your system.

    > If yes, then
    > unexpected RST won't be sent back by the stack. Please let me know if
    > you have some code example as asked in my previous response. Thanks.
    >
    > sls




  9. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent - libnet_write(l) was used

    On Sep 26, 8:16 am, Lew Pitcher wrote:
    > On Sep 25, 11:04 am, slsworking wrote:
    >
    >
    >
    > > On Sep 24, 11:51 am, Lew Pitcher wrote:

    >
    > > > On Sep 24, 10:15 am, slsworking wrote:

    >
    > > > > When a SYN packet was sent from the client machine to the port 25 of a
    > > > > remote machine via the libnet_write. A RST packet (the 3rd packet
    > > > > listed below) was sent right away from the client before or after the
    > > > > SYN|ACK packet was sent back from the server machine. That RST seemed
    > > > > to be sent by the TCP stack because the TCP client didn't send it. Can
    > > > > you explain and resolve this unknown RST problem during establishing
    > > > > the TCP connection? My goal is to avoid the RST packet being sent so
    > > > > that the TCP connection can be established and other SMTP commands can
    > > > > be sent from the client thereafter. Any Idea? Thanks in advance.

    >
    > > > > Packets captured and libnet codes sending the SYN and ACK packets are
    > > > > listed below:

    >
    > > > > Packet number 1:
    > > > > From: 10.103.3.80 To: 10.103.3.79
    > > > > seq: 1500
    > > > > ack: 0
    > > > > th_flags: 2
    > > > > Protocol: TCP
    > > > > Src port: 27
    > > > > Dst port: 25
    > > > > Payload (0 bytes):
    > > > > Hex values:

    >
    > > > > Packet number 2:
    > > > > From: 10.103.3.79 To: 10.103.3.80
    > > > > seq: 1540646009
    > > > > ack: 1501
    > > > > th_flags: 12
    > > > > Protocol: TCP
    > > > > Src port: 25
    > > > > Dst port: 27
    > > > > Payload (0 bytes):
    > > > > Hex values:

    >
    > > > > Packet number 3:
    > > > > From: 10.103.3.80 To: 10.103.3.79
    > > > > seq: 1501
    > > > > ack: 0
    > > > > th_flags: 4
    > > > > Protocol: TCP
    > > > > Src port: 27
    > > > > Dst port: 25
    > > > > Payload (0 bytes):
    > > > > Hex values:

    >
    > > > > Packet number 4:
    > > > > From: 10.103.3.80 To: 10.103.3.79
    > > > > seq: 1501
    > > > > ack: 1540646010
    > > > > th_flags: 10
    > > > > Protocol: TCP
    > > > > Src port: 27
    > > > > Dst port: 25
    > > > > Payload (40 bytes): E..(....@.^r.g.P.g.O............P....]..
    > > > > Hex values: 45 00 00 28 00 f2 00 00 40 06 5e 72 0a 67 03 50 0a 67 03
    > > > > 4f 00 1b 00 19 00 00 05 dc 00 00 00 00 50 02 7f ff 0e 5d 00 0a

    >
    > > > [snip]

    >
    > > > OK, let me see if I can summarize the sequence of events

    >
    > > > 1: Using an API that bypasses the normal TCP/IP facilities and builds
    > > > it's own TCP records on top of RAW sockets, you send out the first
    > > > part of the three way handshake (the SYN).

    >
    > > > 2: To this, the other end responds with the 2nd part of the handshake
    > > > (a SYN,ACK)

    >
    > > > 3: Again, using the bypass API, you build your own ACK to complete the
    > > > handshake, but before you can send it, something on your side sends an
    > > > RST.

    >
    > > > Let's ignore the server for a moment, and just concentrate on what
    > > > your client-side TCP/IP stack sees. Since you use raw sockets, your
    > > > client side TCP/IP stack is unaware that you have appropriated TCP
    > > > port 27 for use in a conversation. Your TCP/IP stack sees a TCP SYN/
    > > > ACK packet for a port that (to it's knowledge) does not have any
    > > > outstanding connections. So, it sends a RST, refusing the SYN/ACK
    > > > packet.

    >
    > > > This happens because you used libnet to bypass the connection
    > > > management facilities (along with everything else) of your TCP/IP
    > > > stack. Either libnet is unable to properly allocate the TCP port on
    > > > your client side, or you have not set the proper options to cause it
    > > > to allocate the port. Either way, your TCP stack is properly handling
    > > > an unsolicited packet by returning a RST. You have to find a way
    > > > within your libnet api to tell the client stack that such connections
    > > > are allowed.

    >
    > > > Why are you using libnet instead of the standard sockets calls? You
    > > > wouldn't have this problem (or the overhead of coding the low-level
    > > > TCP handshake into your application) if you used the appropriate
    > > > system calls instead of this api to "construct and inject network
    > > > packets".

    >
    > > > HTH
    > > > --
    > > > Lew- Hide quoted text -

    >
    > > > - Show quoted text -

    >
    > > Lew:

    >
    > > >> Why are you using libnet instead of the standard sockets calls? You
    > > >> wouldn't have this problem (or the overhead of coding the low-level
    > > >> TCP handshake into your application) if you used the appropriate
    > > >> system calls instead of this api to "construct and inject network
    > > >> packets".

    >
    > > Do you know where to get sample calls of the standard sockets calls?
    > > My purpose is to establish the TCP connection with the sendmail at the
    > > port 25 and send series of SMTP commands thereafter. Thanks again.

    >
    > Take a look athttp://www.frostbytes.com/~jimf/papers/sockets/sockets.html
    > which is an html-ified version of a standard "introduction to sockets"
    > paper written 20 years ago. This should get you started in sockets
    > programming.


    Also, for a little more detail, try http://beej.us/guide/bgnet/


  10. Re: TCP client machine (Linux) sent the unexpected RST right after the SYN was sent -

    [QUOTE=unix;217356]And if you must use your own stack you should make certain that the IP
    and ARP saps are not bound to the interface(s) in question by the host
    stack.

    rick jones


    Can you please elaborate? I'm having a similar issue in my small network running 'custom' stacks used by such tools.

+ Reply to Thread