Raw Sockets + Userland TCP Kernel Resetting Packet

[Bradley Falzon]

Hi,

I'm writing a program to assist in learning/debugging tcp stacks, it
creates a raw socket and replicates an exceedingly simple tcp stack. By
which I mean, it sends and receives packets, setting correct flags,
payloads etc.

One difficulty I've come across, after I've created a raw socket and sent
my syn packet, when the syn+ack packet arrives from the peer, my program
receives it fine - but the kernel also resets the connection.

Example tcpdump dump where 192.168.1.12 is the program and 192.168.1.1 is
the remote peer I'm trying to establish a connection with:
08:33:36.660321 IP 192.168.1.12.47775 > 192.168.1.1.80: Flags [S], seq
1023, win 0, length 0
08:33:36.660665 IP 192.168.1.1.80 > 192.168.1.12.47775: Flags [S.], seq
640280152, ack 1024, win 14600, options [mss 1460], length 0
08:33:36.660682 IP 192.168.1.12.47775 > 192.168.1.1.80: Flags [R], seq
1024, win 0, length 0

In previous iterations of this, I've simply created a iptables rules entry
to drop this packet, but I feel there might be a better way. Others have
mentioned to also bind to the socket, but this doesn't appear to be working.

I've been trying to trace the path through the kernel to find out if
there's any support for what I'm trying to do (effectively discard the
packet).

The code itself is written in Go, but the following are the syscalls I'm
using (output from systrace):
socket(PF_INET, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_TCP) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.12")}, 16) = 0

I don't believe the bind call is actually required, and I've used hping
utility which uses socket(PF_PACKET, SOCK_RAW, 768) and exhibits the same
behaviour (syn+ack is reset).

Also, I'm not debating the behaviour of the Kernel, just whether I can do
anything to change it.

Is there another option, or if this is too far off topic another place I
could ask?

Thanks

-- 
Bradley Falzon
brad at teambrad.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151125/01f95372/attachment.html