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

.



Relevant Pages

  • Re: tcp 139 or 445
    ... at both port 139 and 445 simultaneously. ... response from either of the ports, the session will fail completely. ... If the client has NBT disabled, it will always try to connect to the server ... Packet: Session Request ...
    (microsoft.public.windows.server.general)
  • Re: How port forwarding programs really work?
    ... NAT not only modifies IP header, but also TCP/UDP (port numbers, etc.) header in every packet. ... Client 1 - ip addr. ... External interface of NAT router and Remote server are connected via Internet. ... The packet gets to 192.168.123.254 - because that address is configured as Default Gateway on Client 1. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Receiving packet for port 1025 unexpectedly causes RST of conn
    ... no data to any port other than the one that I've specified. ... Maybe if you look at the actual data in the packet you'll ... // to that port periodically for 60 seconds, then close the connection. ... PC sends the RST. ...
    (microsoft.public.windowsce.embedded)
  • Re: Receiving packet for port 1025 unexpectedly causes RST of conn
    ... The packet for port 1025 is coming from the CE device, ... PC sends the RST. ... before dumping the connection to 1030, but I don't see any evidence that CE ...
    (microsoft.public.windowsce.embedded)
  • Re: Q: How do stealth ports manage to accept a connection?
    ... "stealth" means that if a packet arrives to that port and ... a firewall will do this even if a process is ... The client always opens the control port, ...
    (comp.security.firewalls)