_sebf - www.frameip.com

Hi,

I send a Tcp frame with the Syn Flag. I use the raw mode and the option
IP_HDRINCL.

My frame arrives to the destination Host. Then the destination Host answers
me
a frame with Syn, Ack flags. But after, my Pc sends a new frame with Rst
flag. But I don't want send this
last frame.

I understand why my Os (Win32) send an Rst frame, because it doesn't
understand the Syn, Ack frame.

How Can I do?

Best regards

--

_SebF

http://www.frameip.com
Un site pour les spécialistes IP

lev walkin

No. It is because your OS does not have a TCP socket listening on that port.


Typically, an OS takes care answering the packets which do not correspond
to the open ports. For example, it may reply with ICMP Port Unreachable
to UDP packets reaching your host when there's no UDP socket established
on a particular port. The same thing applies to TCP: when a packet is
received by an operating system, and there is no listening socket or
already established communication, the OS takes liberty at refusing
such a packet.

You have several options:

1. Establish a [temporary] IP filter to "eat" resets generated by
your OS.
2. Some OS'es have a writeable property governing their behavior
in such cases. I don't know much about Windows, but most unixes
have net.inet.tcp.blackhole variable which can be enabled to
disallow sending resets for such packets. Windows may have a
registry option.
3. Open a TCP socket, bind it to some local port, and use that
local port when sending the custom-crafted packets. The operating
system is likely to respond differently.

--
Lev Walkin
vlm@lionet.info

_sebf - www.frameip.com

"Lev Walkin" <vlm@lionet.info> a écrit dans le message de news:
2mi7bjFmdohpU1@uni-berlin.de...


But I tried with a Tcp socket listening on that port too.

Thx


Ok

If someone knows which registry option....

I have a friend in the same situation, but he uses Linux system. Can you
explain me how he can do?

Sorry, but I tried the idea, but my Os send the same Rst frame. Certainly
because Windows receive a SynAck frame without seen the Syn frame.


--

_SebF

http://www.frameip.com
Un site pour les spécialistes IP

lev walkin

On BSD, I was able to do it with
sysctl -w net.inet.tcp.blackhole=1

On Linux, an IP filter (iptables) "BLACKHOLE" or "DROP" feature may be
employed.


--
Lev Walkin
vlm@lionet.info

alun

You will need to make sure that the OS doesn't interpret incoming TCP
packets. What you are looking to do is to either replace the Windows TCP/IP
stack with one of your own writing, or insert your code underneath the
Windows TCP/IP stack that filters these packets out.

The terms you will need to look for are "Base Service Provider" (BSP), and
"Network Driver Interface Specification" (NDIS).

Both of these are lower than the Winsock layer. You seem to be pretty
adamant that you don't want to do anything more than write a Winsock
application, and I'm afraid that in that case, you're stuck. There is no
way from a Winsock application to spoof TCP using raw sockets without the
existing TCP layer catching the responses and resetting them.

Alun.
~~~~

keith wansbrough

"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> writes:

This ought to be FAQ.

Q: I am using raw sockets to emit a TCP SYN packet. When the SYN/ACK
response comes, my OS stack replies with a RST before I can reply with
an ACK. Why, and what can I do?

A: Your OS stack knows nothing about the connection you are trying to
establish, and so it sees a SYN/ACK arriving for a connection it
didn't initiate. It replies, correctly, with a RST. Your OS stack
assumes, reasonably, that it is responsible for all TCP communication
to/from your host.

The easiest way to avoid this is to simulate a TCP connection not from
your own machine's IP address, but from another IP address on the same
subnet that is *not* currently used by another machine. You can
receive packets by packet sniffing - set your NIC to promiscuous mode
and use libpcap or similar - and you can send using raw sockets in the
same way as before. This way your OS will just ignore the incoming
SYN/ACK, since it is addressed to another machine.


HTH.

--KW 8-)
--
Keith Wansbrough <kw217@cl.cam.ac.uk>
http://www.cl.cam.ac.uk/users/kw217/
University of Cambridge Computer Laboratory.