* Raw Sockets + Userland TCP Kernel Resetting Packet
@ 2015-11-25 0:27 Bradley Falzon
2015-11-25 16:25 ` michi1 at michaelblizek.twilightparadox.com
0 siblings, 1 reply; 2+ messages in thread
From: Bradley Falzon @ 2015-11-25 0:27 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Raw Sockets + Userland TCP Kernel Resetting Packet
2015-11-25 0:27 Raw Sockets + Userland TCP Kernel Resetting Packet Bradley Falzon
@ 2015-11-25 16:25 ` michi1 at michaelblizek.twilightparadox.com
0 siblings, 0 replies; 2+ messages in thread
From: michi1 at michaelblizek.twilightparadox.com @ 2015-11-25 16:25 UTC (permalink / raw)
To: kernelnewbies
Hi!
On 10:57 Wed 25 Nov , Bradley Falzon wrote:
> 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.
You might be able to use the tun/tap device. It basically creates a network
interface with a file descriptor of your program being the other side of it.
See Documentation/networking/tuntap.txt (in the kernel source) for more
details.
Is this an option for you?
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-11-25 16:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-25 0:27 Raw Sockets + Userland TCP Kernel Resetting Packet Bradley Falzon
2015-11-25 16:25 ` michi1 at michaelblizek.twilightparadox.com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).