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@teambrad.net