title: raw sockets not an ACK to my SYN
body: <p>I've been educating myself about the use of raw sockets, as I've always found lower-level networking very interesting. The goal here is not to completely reimplement TCP using raw sockets, but rather to learn how to engage in a 3way handshake for myself (bypassing the kernel).</p>
  
  <p>For my example, I have written a small program which will create an IP Header with user-supplied source and destination addresses, filling in TCP for protocol, making up an arbitrary 16 bit identification, setting version to 4, length to 5, and flags to 2 (don't fragment). The IP header does this for every packet it crafts (and is working just fine, in fact with the exception of addresses and ident has all the same bits as a known good TCP SYN packet). It then crafts a TCP Header with user supplied ports, a random sequence number, 0 ACK, an offset of 5 (unless options), flags set to 2 (SYN), and an arbitrary window size (I've been using 32792). I have tried varying degrees of TCP options hoping that perhaps one of them were thwarting my efforts, so sometimes this header has changed a bit in effort to get things working.</p>
  
  <p>The program is written in python, using raw sockets with address family AF_INET, and protocol IPPROTO_RAW (though I've also tried IPPROTO_TCP). So I fired up wireshark, and shot a SYN at a user application waiting on a TCP connection. Wireshark shows the SYN, and shows no errors associated with the packet, but that's the end of the story... No SYN/ACK, no RST, just nothing. No errors in syslog, the user application saw nothing, and a check of iptables ensures that there are no firewall rules. It may be worth noting that all my testing so far has been all on the same address "127.0.0.1", and for these initial responses the only thing spoofed is the source port. I've been testing this on slackware 14.0 (running in a VM).</p>
  
  <p>The strange part is, firing up the client user application (that is the client to the simple server I was targeting) and connecting via tcp sockets shows an initial SYN that only differs from my packet in a few bytes: tcp.s_port, tcp.checksum, ip.checksum, ip.identification. Yet immediately the server responds to the client's SYN with a SYN/ACK. I cannot for the life of me figure out where my hand-crafted packet is getting dropped. For the sake of debugging this I turned off TCP Timestamps and Window Sizes. Can anyone shed some light on what might be inhibiting me</p>
  
  <p><strong>Update</strong>
  Code is here: <a href="http://pastebin.com/2aHWYGxb#" rel="nofollow">http://pastebin.com/2aHWYGxb#</a><br>
  Doing a bit more reading on TCP checksum calculation, and I stumbled upon this:  <a href="http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader-2.htm" rel="nofollow">http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader-2.htm</a><br>
  which explains a different method than I have ever seen before, perhaps this is how it is done now? Not real sure, but I'm working on that now.</p>
  
  <p>Following the article above and reimplementing the checksum function to be computed over the pseudo-header, tcp header (with 0 for checksum), and the payload shows no improvement. The altered code can be found at the pastebin link: k6bwFvX6<br>
  I'm pretty certain, by now, that the problem does lie in that checksum calculation, but for the life of me cannot see what is wrong with it.</p>
  
  <p>After further review, turns out I was operating the checksum function on bytes rather than halves and I forgot a shift operation. It's all working now, thank you to those who offered their help.</p>