Add support for TCP without libpcap

[khorben]

From original comments in the code:

        /* Though hacky and clunky, we just sleep for a second then
         * close the socket.  No need to read or write anything.  This
         * just gives the client a sufficient window to send their
         * request on this socket. In any case the socket is closed
         * after that time.
        */

From what I understand, TCP support is actually implemented over libpcap, and the TCP service simply allows handshakes to take place for the client to send the data. There is no fragment reassembly however, so this could easily silently break, unless the TCP data is actually handled properly.

[mrash]

Yes, the SPA packet data is still read via libpcap instead of fwknopd reading the data from the TCP socket itself. As you said, it is simply a TCP service so that the fwknop client can send the data over an established TCP connection. Agreed that splitting SPA data across TCP segments would be an issue, but this whole mechanism is only for rare cases where a user really wants to send SPA packets over TCP. In some sense, we should just remove this capability, since a major design goal of SPA is to not have a scannable SPA service. An unacknowledged UDP service is fine under this requirement, but this is not possible with TCP.

[Shyam-Makwana]

Why fwknopd is reading the SPA packet data from libpcap rather than reading from Socket itself? Is there any disadvantage to reading data directly from Socket because that would be easy and less time-consuming for the server to read the SPA packet directly from Socket?

Anyone can answer my question and kindly reply asap because currently, I'm working on this project to create fwknopd (Server ) for Windows system.