On Tue, Feb 26, 2013 at 7:55 PM, <firstname.lastname@example.org>
On Tue, 26 Feb 2013 22:27:48 +1100 "Sebastien J." <email@example.com>
>The client won't send the TCP payload if the 3-way handshake
>doesn't establish the TCP connection.
ok, yeah I just had a look..which led me to track back to Michael's
dc14 talk...digest doesn't fit in a SYN packet.
Some additional detail as well - the fwknop client can send SPA packets over crafted SYN packets if the local user has root privileges (see the "-P tcpraw" command line argument). However, the main reason SPA over TCP was added was to make it easy to send SPA packets through Tor. Because Tor only establishes virtual circuits through the Tor router cloud for established TCP connections with entry routers, if SPA is to work there then it must use a real TCP connection. This is the same reason that Nmap SYN scans can't be done through Tor - only TCP connect() (nmap -sT) scans will work. Also, even though I don't think the TCP RFC technically forbids data to be included within the initial SYN of a connection, some intrusion detection systems flag such traffic as suspicious. (Whether it's "really" suspicious is another question - I'm just pointing out that IDS's may flag such communications.)
Now, on the libpcap side, the fwknop daemon does continue to use libpcap. And, this happens regardless of whether the lightweight TCP server is also started. If the TCP server is not enabled and SPA packets can be sent against another TCP server that may be listening, then you can just set the PCAP_FILTER statement in the fwknopd.conf file to have fwknopd examine TCP traffic for SPA data. If another server is not available, then the TCP server bundled with fwknop can be used for the same purpose. In this case, it would probably be better to just use the TCP server itself to acquire incoming SPA packets instead of using libpcap.