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.

On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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

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

On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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.

On Sep 24, 11:51 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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

On Sep 24, 1:21 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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

On Sep 25, 11:04 am, slsworking <slswork...@gmail.com> wrote:
> On Sep 24, 11:51 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
>
>
>
> > On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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.

On Sep 25, 11:12 am, slsworking <slswork...@gmail.com> wrote:
> On Sep 24, 1:21 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:
>
> > On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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

On Sep 26, 8:16 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> On Sep 25, 11:04 am, slsworking <slswork...@gmail.com> wrote:
>
>
>
> > On Sep 24, 11:51 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
>
> > > On Sep 24, 10:15 am, slsworking <slswork...@gmail.com> 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/